Link Details

Link 962919 thumbnail
User 419506 avatar

By mpegram3rd
via blogs.captechconsulting.com
Published: May 01 2013 / 08:36

Unit testing can be fairly simple to implement with immeasurable value for both the customer and the implementing team. Unfortunately more often than not, basic principles and tools that can help prevent these problems are not being applied. What follows are proven guiding principles to successful unit testing.
  • 34
  • 0
  • 1882
  • 1290

Comments

Add your comment
User 131259 avatar

DavidKarr replied ago:

0 votes Vote down Vote up Reply

This blog page doesn't allow comments, so I'll put them here. You start out with a list of "If any of the following are true ...", but you never directly address these specific issues. You should point out specifically why, if you have these problems, what unit testing guideline you're working against. Your later content addresses some of these indirectly, but you should directly correlate them. Concerning strict vs. nice mocks: I believe that preferring strict mocks is misguided. The general acceptance of this fact is partially why Mockito is more popular than EasyMock. The important point to realize is that tests are there to validate essential business logic. It is not necessary to validate every behavior of mocked objects, especially the behavior that is not critical or essential business logic. You say: "When testing for an expected exception, wrap in a try/catch and add a fail immediately after the call that should fail:" Actually, it's much easier to use the "expected" property of the "@Test" annotation. Your example is much more concise like this: @Test(expected = MyExceptino.class) public void expectedException () throws Exception { testClass.someFailure() } Concerning assertions, I avoid JUnit assertions and always use fest-assert (http://code.google.com/p/fest/). This results in more readable assertions.

User 419506 avatar

mpegram3rd replied ago:

0 votes Vote down Vote up Reply

DavidKarr, truly, thanks for your feedback. A couple of comments.... 1. I disagree with your assessment of why Mockito is popular. I believe if you look at what most people like about Mockito, it's the syntax and (slightly less) ceremony required to use the framework. It certainly has those advantages over EasyMock, and there's nothing wrong with using it. That said, if you review my comments on nice vs strict, I said "prefer strict" but I also mention that there are occasions where "nice" makes sense (when measuring a behavior is not important). A common example of this is when testing a subclass. I'll often partially mock the class under test and allow for "nice mock" behavior for parent methods. 2. @Test(expected) is also a great way of testing for an expected exception. I agree and it would make a worthy addition to the blog entry. 3. Honestly I was unfamiliar with FEST, but given a cursory look at the tool, I have to say I really dig the fluent assertion interface so big thanks for pointing that out to me.

User 419506 avatar

mpegram3rd replied ago:

0 votes Vote down Vote up Reply

Sorry.. one other point to clarify... @Test(expected=...) is good if you're not using mocks, and/or don't wish to do any validation after the exception has occurred, however if you plan on running the mock "verify" process, or making assertions on the thrown exception, the try...fail...catch pattern I talk about is the only way to do so.

User 131259 avatar

DavidKarr replied ago:

0 votes Vote down Vote up Reply

I see no reason why using "expected" is exclusive of using mocks. In fact, most exception check test cases would very likely be using mocks, because you'll have to set up mock scenarios that cause exceptional conditions to occur. I would agree that if you need to verify something about the thrown assertion, then you definitely need the more explicit try/catch structure.

User 755021 avatar

devent replied ago:

-1 votes Vote down Vote up Reply

One more suggestion: Use a dynamic or DSL like language for your tests, like Groovy. Because that code looks like from a horror movie: List forecasts = weatherWS.getForecasts("23238"); // Test for non-empty list. assertThat(forecasts, notNullValue()); assertThat(forecasts, hasSize(greaterThan(0)); // test for item in list assertThat(forecasts, hasItem(expectedForecast)); // Evaluate and test contents of the list. for (ForecastDay dayForecast : forecasts) { assertThat(dayForecast.zipCode, equalTo("23238")); assertThat(dayForecast.getLow(), lessThan(dayForecast.getHigh()); } With Groovy it will be much more clear: def forecasts = weatherWS.getForecasts("23238"); // Test for non-empty list. assert !forecasts.find({ it == null }) assert forecasts.size() > 0 // test for item in list assert forecasts.find({it == expectedForecast }) // Evaluate and test contents of the list. forecasts.each { assert it.zipCode == "23238" assert it.low < it.high } PS: Good luck reading my comment. D-Zone comments sucks ass.

User 419506 avatar

mpegram3rd replied ago:

0 votes Vote down Vote up Reply

devent, thanks for your comment. I agree that the syntax can get a bit wordy. The intent of the article was to address problems I commonly see with "unit tests" which often turn out to be integration tests, or fail to cover important negative scenarios. I personally like what I've seen with Spock and hope to put together a blog entry which focuses on Spock at a later date. The FEST framework an earlier commenter pointed out also seems to go a long way toward making the code more readable.

Add your comment


Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.

Debugging JavaScript
Written by: Ashutosh Sharma
Featured Refcardz: Top Refcardz:
  1. Design Patterns
  2. OO JS
  3. Cont. Delivery
  4. Java EE7
  5. HTML5 Mobile
  1. Java EE7
  2. Spring Annotations
  3. Git
  4. Java
  5. REST