ChaiPuter

Unit tests should be done wisely (Note: I suggest reading my previous post about Mocks before this one) It is easy to fall into the unit test biggest pitfall - dumb unit tests. What is the recipe for a popular unit-test pitfall ? Assume unit tests are very important Test everything verify every method call Get 100% coverage Yes, the above is bad. The most obvious problem you will find yourself struggling with will be failing tests regularily, and changing the tests to pass those failure points. That is the direct opposite target we want to achieve from unit tests. Upgrading of a unit test happens, but it shouldn't happen too much unless you specifically changed code in order to change the business logic. When a test fails, it should point to a problem with the code not with the test. Why do we fall to this pitfall ? Because we: Create unfocused unit tests  We test all the easy things instead of testing the important things We te...

Mocking is a term used to describe a wide array of types, which is inaccurate. Well, now that everyone uses it as a general term, I assume it is ok to have one word to rule them all, but still, just for the sake of accuracy I will post here a short explanation. When doing mocking today, we usually use a mocking framework eg: Mockito etc... This framework allows the developer to mock an object for testing (or any other) purposes. Why mock ? Why will we want to mock an object instead of using the original one ? Maybe the original one is very complex Maybe the original one demands resources we don't want to mess with Maybe using the original one can have a restriction on our code Other things... So we want to use mocks. What can we do with them ? Sometimes we want to construct an object which needs an other object in it's constructor's argument list, we will just mock that argument and send it to the constructor - quick and easy. S...

When an exception is thrown in a unit test, the unit test will fail, giving a red bar - unless there is a try/catch that catches the exception and swallows it quietly.  Therefore, you should make sure that catching an exception in a unit test is indeed what you really mean to do.  Should the test really handle the error and continue, perhaps succeeding, or should the test fail, giving a visual indication that something went wrong? I'd add that when the right behavior of a test case is a thrown Exception, one should add to the @TEST annotation one's expectation.  e.g. @Test(expected = NumberFormatException.class)

My boss wanted me to deliver a full list of all of my JUnit tests I did on my code. When he saw my exasperated expression he offered me to just export the test's javadocs and deliver it as a report, well that made me happy :-) I've adopted writing javadocs all of the time as a good coding practice, so this task shouldn't have made me any problems, but... it did. As you well know, I use Eclipse as my IDE, so I just went to file --> export --> javadoc. Cool, everything seemed to work like a charm, till I looked at the javadocs - all was documented nicely except for - the method's javadocs, and that is where most of my javadocs are written. What was my problem? I found out that because I use JUnit 4 as my unit testing engine, I must use a @Test annotation, then I write my javadoc, here's my bug, apparently, when the tool sees an annotation it assumes the method's declaration has started, so when it tries exporting javadocs it doesn't look after any annota...

Each time I want to create a JUnit test class, I take a look at an older one, copy it, then remove all of the specifics of the previous tests. That isn't a good practice  :-) So I've decided to do it once more, in order to create a template - a working JUnit class which doesn't do anything, just add your specific code you want to test and run along: package org.chaiavi.TestJunit; import java.io.IOException; import org.junit.*; import static org.junit.Assert.*; public class TestJunit{ /** Use this method for all of the lines of code you want to run before the whole JUnit Class. */ @BeforeClass     public static void unitSetup() throws Exception { } /** Use this method for all of the lines of code you want to run after the whole JUnit Class. */ @AfterClass     public static void unitCleanup() throws Exception {     }  /** Use this method for all of the lines of code you want to run before each JUnit test. */ @Before     public void methodSetup() throws Exception ...

Unit Tests and Code Coverage Unit Tests In computer programming, unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is a method; which may belong to a base/super class, abstract class or derived/child class. Ideally, each test case is independent from the others; mock objects and test harnesses can be used to assist testing a module in isolation. Unit testing is typically done by developers and not by end-users. (Taken from WikiPedia) Code Coverage The Unit tests are a good measure of testing, but how much of the code is being covered? Did the unit test check all of the paths of the code flow? These are the issues the Code coverage helps us solve. The Code Coverage Tools run the Unit Tests we created and tell us explicitly how much cod...