Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Even though developers have switched from junit 3.x to 4.x I still see the following 99% of the time:

@Before
public void setUp(){/*some setup code*/}

@After
public void tearDown(){/*some clean up code*/}

Just to clarify my point... in Junit 4.x, when the runners are set up correctly, the framework will pick up the @Before and @After annotations no matter the method name. So why do developers keep using the same conventional junit 3.x names? Is there any harm keeping the old names while also using the annotations (other than it makes me feel like devs do not know how this really works and just in case, use the same name AND annotate as well)?

Is there any harm in changing the names to something maybe more meaningful, like eachTestMethod() (which looks great with @Before since it reads 'before each test method') or initializeEachTestMethod()?

What do you do and why?

I know this is a tiny thing (and may probably be even unimportant to some), but it is always in the back of my mind when I write a test and see this. I want to either follow this pattern or not but I want to know why I am doing it and not just because 99% of my fellow developers do it as well.

share|improve this question

3 Answers 3

up vote 4 down vote accepted

People use the same method names because it is a convention and people know it already. There is nothing exactly wrong with using a different name, it makes things a little harder. I don't think your examples are any clearer than just using setUp().

At the end of the day, people do it because 99% of their fellow developers do it. If you have a test class that is doing something very distinctive in it's setup method that you think a more specific name helps, then you can do that. However, at the same time, I would consider taking a second look at the test if it's setup method is doing enough work that setUp() isn't descriptive enough. Does the test have too many dependencies? Can you break it down into smaller units?

share|improve this answer

I always call it setUp because there is very little to be gained in terms of making my tests more informative. If I saw someone call setUp something else, I would expect that new name to be particularly important somehow because of the divergence from the standards.

share|improve this answer

I do use setUp() when I can't think of a better name. Part of the problem is that the setUp method has a variety of things in it so another name doesn't present itself.

There is a problem with using setUp for all the methods. You have to remember to call the superclass setUp if it exists. Unlike in JUnit 3.8 where you could just do so all the time.

When I am writing an abstract test I make an effort to use a name that is not setUp() to avoid putting this burden on the subclass implementers. Granted it is pretty obvious there is a problem due to the NullPointer. But writing a test superclass is like writing reusable code. You want to make things easy for the callers!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.