Do you write unit tests for all the time in TDD?
- by mcaaltuntas
I have been designing and developing code with TDD style for a long time. What disturbs me about TDD is writing tests for code that does not contain any business logic or interesting behaviour. I know TDD is a design activity more than testing but sometimes I feel it's useless to write tests in these scenarios.
For example I have a simple scenario like "When user clicks check button, it should check file's validity". For this scenario I usually start writing tests for presenter/controller class like the one below.
@Test
public void when_user_clicks_check_it_should_check_selected_file_validity(){
MediaService service =mock(MediaService);
View view =mock(View);
when(view.getSelectedFile).thenReturns("c:\\Dir\\file.avi");
MediaController controller =new MediaController(service,view);
controller.check();
verify(service).check("c:\\Dir\\file.avi");
}
As you can see there is no design decision or interesting code to verify behaviour. I am testing values from view passed to MediaService. I usually write but don't like these kind of tests. What do yo do about these situations ? Do you write tests for all the time ?
UPDATE :
I have changed the test name and code after complaints. Some users said that you should write tests for the trivial cases like this so in the future someone might add interesting behaviour. But what about “Code for today, design for tomorrow.” ? If someone, including myself, adds more interesting code in the future the test can be created for it then. Why should I do it now for the trivial cases ?
