FAQ: Unit Testing - Test Fixtures

Frequently Asked Questions Python FAQ
1

Community%20FAQs%20on%20Codecademy%20Exercises
Community%20FAQs%20on%20Codecademy%20Exercises1000×208 141 KB

This community-built FAQ covers the “Test Fixtures” exercise from the lesson “Unit Testing”.

Paths and Courses
This exercise can be found in the following Codecademy content:

Learn Intermediate Python 3

FAQs on the exercise Test Fixtures

There are currently no frequently asked questions associated with this exercise – that’s where you come in! You can contribute to this section by offering your own questions, answers, or clarifications on this exercise. Ask or answer a question by clicking reply (reply) below.

If you’ve had an “aha” moment about the concepts, formatting, syntax, or anything else with this exercise, consider sharing those insights! Teaching others and answering their questions is one of the best ways to learn and stay sharp.

Join the Discussion. Help a fellow learner on their journey.

Ask or answer a question about this exercise by clicking reply (reply) below!
You can also find further discussion and get answers to your questions over in Language Help.

Agree with a comment or answer? Like (like) to up-vote the contribution!

Need broader help or resources? Head to Language Help and Tips and Resources. If you are wanting feedback or inspiration for a project, check out Projects.

Looking for motivation to keep learning? Join our wider discussions in Community

Learn more about how to use this guide.

Found a bug? Report it online, or post in Bug Reporting

Have a question about your account or billing? Reach out to our customer support team!

None of the above? Find out where to ask other questions here!

2

Why do we have result:

Power cycling bluetooth device…
Testing Feature A
Power cycling bluetooth device…
Power cycling bluetooth device…
Testing Feature B
Power cycling bluetooth device…

After executing those example code:

def power_cycle_device():
    print('Power cycling bluetooth device...')
 
class BluetoothDeviceTests(unittest.TestCase):
    def setUp(self):
        power_cycle_device()
 
    def test_feature_a(self):
        print('Testing Feature A')
 
    def test_feature_b(self):
        print('Testing Feature B')
 
    def tearDown(self):
        power_cycle_device()

can not understand :frowning:

3

You are very inconsiderate my little boy:

A method named setUp runs before each test case in the class. Similarly, a method named tearDown gets called after each test case.

:face_with_monocle:

4

Why did we replace our setUp method with the setUpClass method and added the @classmethod decorator. ?
what does @classmethod do with setUpClass?

5

Your questions tie together somewhat so I’ll try to answer them both at once. We get that output because the methods setUp and tearDown are called before every test we perform.

So we have the first test test_feature_a which behaves in the following way-
setUp() → Power cycling bluetooth device…
test_feature_a() → Testing Feature A
tearDown() → Power cycling bluetooth device…

Then the second test:
setUp() → Power cycling bluetooth device…
test_feature_b() → Testing Feature B
tearDown() → Power cycling bluetooth device…

Using the setUpClass as a class method means this method is called once before any testing is run and tearDownClass is run after all the tests are complete. So the biggest difference is when and how often these methods are called.

setUpClass() → Power cycling bluetooth device…
test_feature_a() → Testing Feature A
test_feature_b() → Testing Feature B
tearDownClass() → Power cycling bluetooth device…

6

I did not understand the purpose of decorator here. Why do we put @classmethod above setUpClass ?
As I remember from video-explanation from Mike What Are Decorators? - YouTube we using wrapper() to “boost” decorating method/function passing it name after “@”. But what are we wrapping in setUpClass with decorator @classmethod?

7

It’s part of the implementation that these need to be wrapped with classmethod-
https://docs.python.org/3/library/unittest.html#setupclass-and-teardownclass

It’s a bit of a guess but I think the implementation is such that every defined test is performed on a new instance of this testing class. So .setUp and .tearDown and run for each and every new instance, whereas we want the set-up to be available for every possible new instance so we use @classmethod around .setUpClass to modify the class itself. I’ve not looked too closely at the implementation of testtunit so I could be wrong. If you wanted a definite you might have to search elsewhere.

2 Likes
9

Struggling to figure out why the @classmethod decorator is needed here and how it does what it does.

Does decorating the setUpClass and tearDownClass methods with the @classmethod decorator simply mean that those methods will be run before and after an instance of the class whenever the instance is run? As opposed to running before and after each method?

Documentation I have found regarding the @classmethod decorator only furthers my confusion.