[ACCEPTED]-Unit testing: Is it a good practice to have assertions in setup methods?-assertions

Instead of assertions in the setup to check 19 the result, I used a simple test (a test method along the others, but 18 positionned as first test method).

I have 17 seen several advantages:

• The setup keeps short and focused, for readability.
• The assertions are run only once, which is more efficient.

Usage and discussion :

For example, I 16 name the method testSetup().

To use it, when 15 I have some test errors in that class, I 14 know that if testSetup() has an error, I 13 don't need to bother with the other errors, I 12 need to fix this one first.

If someone is 11 bothered by this, and wants to make this 10 dependency explicit, the testSetup() could 9 be called in the setup() method. But I don't 8 think it matters. My point is that, in JUnit, you 7 can already have something similar in the 6 rest of your tests:

1. some tests that test local code,
2. and some tests that is calls more global code, which indirectly calls the same code as the previous test.

When you read the test 5 result where both fail, you already have to take care of this dependency that is not in the test, but in the code being called. You have to fix 4 the simple test first, and then rerun the 3 global test to see if it still fails. This 2 is the reason why I'm not bothered by the 1 implicit dependency I explained before.

Having assertions in the Setup/TearDown 15 methods is not advisable. It makes the test 14 less readable if the user needs to "understand" that 13 some of the test logic is not in the test 12 method. There are times when you do not 11 have a choice but to use the setup/teardown 10 methods for something other than what they 9 where intended for.

There is a bigger issue 8 in this question: a test that calls another 7 test, it is a smell for some problem in 6 your tests. Each test should test a specific 5 aspect of your code and should only have 4 one or two assertions in it, so if your 3 test calls another test you might be testing 2 too many things in that test. For more information 1 read: Unit Testing: One Test, One Assertion - Why It Works

They're different scenarios; I don't see 26 the similarity.

Setup methods should contain 25 code that is common to (ideally) all tests 24 in a fixture. As such, there's nothing 23 inherently wrong with putting asserts in 22 a test setup method if certain things must 21 be true before the rest of the test code 20 executes. The setup is an extension of 19 the test; it is part of the test as a whole. If 18 the assert trips, people will discover which 17 pre-requisite failed.

On the other hand, if 16 the setup is complicated enough that you 15 feel the need to assert it is correct, it 14 may be a warning sign. Furthermore, if 13 all tests do not require the setup's full 12 output, then it is a sign that the fixture 11 has poor cohesion and should be split up 10 based on scenarios and/or refactored.

It's 9 partly because of this that I tend to stay 8 away from using Setup methods. Where possible, I 7 use private factory methods or similar to 6 set things up. It makes the test more readable 5 and avoids confusion. Sometimes this is 4 not practical (e.g. working with tightly 3 coupled classes and/or when writing integration 2 tests), but for the majority of my tests 1 it does the job.

Follow your heart / Blink decisions. Asserts 21 within a Setup method can document intent 20 ; improver readability. So personally I'd 19 back you up on this.
It is different from 18 a test calling other tests - which is bad. No 17 test isolation. A test should not influence 16 the outcome of another test.

Although it 15 is not a freq use-case, I sometimes use 14 Asserts inside a Setup method so that I 13 can know if test setup has not taken place 12 as I intended it to; usually when I'm dealing 11 with components that I didn't write myself. An 10 Assertion failure which reads 'Setup failed!' in 9 the errors tab - quickly helps me zone in 8 on the setup code instead of having to look 7 at a bunch of failed tests.

A Setup failure 6 usually should cause all tests in that fixture 5 to fail - which is a smell that your nose 4 should soon pickup. 'All tests failed usually 3 implies Setup broke ' So assertions are 2 not always needed. That said be pragmatic, look 1 at your specific context and 'Add to taste.'

I use Java asserts, rather than JUnit ones, in 5 the cases where something like this is necessary. e.g. when 4 you use some other utility class to set 3 up test data.:

byte[] pkt = pktFactory.makePacket(TIME, 12, "23, F2");
assert pkt.length == 15;

Failing has the implication 2 'system is not in a state to even try to run 1 this test'.