0

I am very new to junit.I was reading a tutorial on http://docs.spring.io/spring/articles/2007/Spring-MVC-step-by-step/part1.html for spring mvc and I found a test class as below :
1.)

package springapp.web;

import org.springframework.web.servlet.ModelAndView;

import springapp.web.HelloController;

import junit.framework.TestCase;

public class HelloControllerTests extends TestCase {

public void testHandleRequestView() throws Exception{       
    HelloController controller = new HelloController();
    ModelAndView modelAndView = controller.handleRequest(null, null);       
    assertEquals("hello.jsp", modelAndView.getViewName());
} }

I can not understand why I need to use TestCase of Junit as an extra burden when I can check the same by creating a simple test class.

 public class TestStub {
     public static void main(String[] args) {
         HelloController controller = new HelloController();
         ModelAndView modelAndView = controller.handleRequest(null, null);
         if(modelAndView.getViewName().equals("hello.jsp")) {
             ...
         } 
     }
 }  

Again mentioning that I am a beginner.

iAmLearning
  • 1,153
  • 3
  • 15
  • 28
  • The code in the second snippet doesn't compile. Are you asking why you have to extend from TestCase? If you use JUnit4, you must not extend from TestCase. But as the URL indicates, the article you read dates from 2007, where JUnit3 was the lastest version. – JB Nizet Oct 30 '13 at 10:37
  • 2
    You're referencing very old documentation. Things are a lot easier today: http://docs.spring.io/spring-framework/docs/current/spring-framework-reference/html/testing.html#spring-mvc-test-framework – Stefan Birkner Oct 30 '13 at 10:37

1 Answers1

1

You could of course create such a class with a main method and apply your own checks and decide if the test is successful or not.

Then you'd be adding more classes, and more tests and things will get a bit messier. Maybe you'd like to run all tests and see their status as a whole, not stopping at the first one that failed. Maybe you'd like to be able to rerun only the tests that failed. Maybe you'd like to run some config section before all of the test methods in a class, and the list can go on.

At this point you'd start tinkering around trying to extract common reusable stuff and create some sort of framework for your needs, which JUnit, TestNg, etc are already. I guess this sounds a bit like reinventing the wheel.

These frameworks have been around for some time so they have been thoroughly tested and they integrate nicely with IDEs and continuous integration tools. Also many of the communities developing widely used frameworks, such as Spring, have put a lot of work in providing a way to facilitate the integration with test frameworks (custom context-aware runners, mock builders, etc), basically making your life easier.

Test classes are "code" as well, and they also have to be clean and well maintained. Using a known test framework makes it easier for team members to understand what you were trying to express, because it "enforces" a standardised way of doing it. This still requires everyone to learn about it, but you have higher chances of reusing that knowledge when switching workplaces, than if you'd be using your own.

I'm sure there are more reasons, but these came to mind as I was reading your question. Stefan has also made a good point, a lot has changed since 2007 and this evolution has made things simpler both with Spring and JUnit4.

Morfic
  • 15,178
  • 3
  • 51
  • 61