Comments on: Easy 2 Test == Less Reason to Test ? http://stuffthathappens.com/blog/2007/11/01/easy-2-test-less-reason-to-test/ Technology and Geek Stuff by Eric Burke Thu, 04 Nov 2010 22:37:00 -0400 http://wordpress.org/?v=2.8.6 hourly 1 By: Alex Miller - Unit testing is dumb http://stuffthathappens.com/blog/2007/11/01/easy-2-test-less-reason-to-test/comment-page-1/#comment-832 Alex Miller - Unit testing is dumb Fri, 02 Nov 2007 15:34:46 +0000 http://stuffthathappens.com/blog/2007/11/01/easy-2-test-less-reason-to-test/#comment-832 [...] just read Eric’s beautiful post on unit testing and it struck a chord (well several). He’s right on that testing [...] [...] just read Eric’s beautiful post on unit testing and it struck a chord (well several). He’s right on that testing [...]

]]> By: Mario Aquino http://stuffthathappens.com/blog/2007/11/01/easy-2-test-less-reason-to-test/comment-page-1/#comment-829 Mario Aquino Fri, 02 Nov 2007 12:54:54 +0000 http://stuffthathappens.com/blog/2007/11/01/easy-2-test-less-reason-to-test/#comment-829 The name class above looks like the kind of thing that would be tested as a side effect of testing some other class containing the business rules which necessitate the existence of the Name class. No user story would call for the Name class to be added to the system but rather for something that either retrieves or uses the data that the Name class encapsulates and *that* would be the target of a test. If we always start with failing tests before writing code that adds new capability to an application, it is inevitable that tests we write will cover classes with trivial complexity. Is it Name classes responsibility to check that it's fields aren't null? I don't think so because Name class is neither the originator nor the consumer of the data. If null values could possibly be handed to Name, I would look at how the system allowed that in the first place. What if the requirement becomes 'First letters of first name and last name should be capitalized for display if they aren't stored that way in the system'? Is that Name classes responsibility or the responsibility of the thing that returns a Name to its caller or the responsibility of the callers' (which displays the values carried by Name instances)? Starting with a failing test that examines those kinds of details will ensure that you cover the implementation of the rules. This way you might not end up with a NameTest that checks the trivial implementation of Name but instead with some other test that accomplishes the same thing. The name class above looks like the kind of thing that would be tested as a side effect of testing some other class containing the business rules which necessitate the existence of the Name class. No user story would call for the Name class to be added to the system but rather for something that either retrieves or uses the data that the Name class encapsulates and *that* would be the target of a test. If we always start with failing tests before writing code that adds new capability to an application, it is inevitable that tests we write will cover classes with trivial complexity. Is it Name classes responsibility to check that it’s fields aren’t null? I don’t think so because Name class is neither the originator nor the consumer of the data. If null values could possibly be handed to Name, I would look at how the system allowed that in the first place.

What if the requirement becomes ‘First letters of first name and last name should be capitalized for display if they aren’t stored that way in the system’? Is that Name classes responsibility or the responsibility of the thing that returns a Name to its caller or the responsibility of the callers’ (which displays the values carried by Name instances)? Starting with a failing test that examines those kinds of details will ensure that you cover the implementation of the rules. This way you might not end up with a NameTest that checks the trivial implementation of Name but instead with some other test that accomplishes the same thing.

]]>