Even though developers have switched from junit 3.x to 4.x I still see the following 99% of the time:@Beforepublic void setUp(){/*some setup code*/}@Afterpublic 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, likeeachTestMethod() (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.
Should I care about Junit redundancy when using setUp() with @Before annotation?
junit;conventions
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?