I'm currently learning about unit testing, specifically JUnit (with Java).

Searching the web I see many threads talking about why you should use it, what type of methods you should use it with but I can't seem to find much information on when you should implement a unit test.

Is it best to incorporate it from the very beginning of a project and then with every method you create, you add a unit test? Or is it something that it's done towards the latter stages when the logic/structure of the program is closer to completion?

  • Don't listen to this railing academic (me), but: "Unit tests are not a substitute for competence, and since most people write stupid test cases that can be compile-time or static-code checked anyway, their functionality is almost entirely duplicated by asserts and a debugger. Unless you're writing safety-critical code, if you're a good programmer and have good design, unit tests are almost always wasted effort. Even then, you should write test cases for modules on real data, not for CS 101 errors that can be found by your compiler." [back to reality; pray continue] – imallett Nov 13 '14 at 4:03

You should write your unit tests very near to when you write your code. "Timely" is one of the five core tenets of unit testing per Clean Code. There's even an approach that advocates writing your unit tests before your code. It's called Test Driven or Test First Development, depending on who you're talking to.

In my experience, it doesn't matter too much if the tests are done first or second, as long as the tests are done before the work as a whole is considered "done". This means having the unit tests done to consider your story/task done.

Doing the tests near the time you do your code lets you:

  • Write better tests since you remember better what the code should be doing. And you remember how the code does it, making bugs quicker to fix once your unit tests find them.
  • Catch bugs earlier, before others use your code. Catching bugs earlier means they're cheaper to fix.
  • Not fall into the "oh, I'll do it later" trap.
| improve this answer | |
  • 4
    "oh, I'll do it later" trap I'm very guilty of that! Thanks for the great answer! – benscabbia Nov 12 '14 at 20:05
  • I'd say it's even more pernicious than "I'll do it later". You really should do them first, because when you do them last, you might code a unit test or two, but there's no way it'll be as good of a set of unit tests as if you did it up front. When you do it after you've written the functional code, you always have in the back of your mind something like "This is a waste of time, I already KNOW this code works inside the real app!" So you don't code them very well -- you're complying with the letter of the law, but not the spirit of good unit testing. – Calphool Nov 12 '14 at 20:19
  • 1
    @JoeRounceville - Not in my experience. I mean, that does happen, but so does the "write test, write code to make that test work and some other code to make that code work, but no test for the other code" scenario. Having the discipline to make good tests is non-trivial in either scenario. – Telastyn Nov 12 '14 at 20:26
  • 1
    "For Agile development shops, this means having the unit tests done during your sprint.": As far as I know, Kanban does not have sprints. I think it would be more precise to say that you have to have your unit tests done before you consider the implementation of some functionality done. – Giorgio Nov 12 '14 at 21:30
  • 1
    @TimSeguine - good luck finding enough competent people who would only write unit tests for a living, and good luck convincing management to pay them enough to get them (instead of cheaper alternatives). – Telastyn Nov 12 '14 at 23:22

You can start unit testing as soon as you have a notion of a class you want to create. The meaning of "unit" will depend on the programming language. For example, suppose you want to create a function to parse roman numerals. You might start with this unit test:

public class RomanTest {
  public void iEquals1() {
    assertEquals(1, Roman.toInteger("I"));

Your test won't compile, because you haven't created the Roman class. So you write:

public class Roman {
  public static toInteger(String s) {
    return 1;

Wow, your first test passed!

| improve this answer | |
  • How much mockup code do you write while writing the tests? – Surt Nov 12 '14 at 23:19
  • As much as needed, but as little as possible. You don't want tests for a calling unit to depend on complex behavior in a called unit. – kevin cline Nov 13 '14 at 0:29

You should start writing your tests when you start writing your code.

The important part is that any code you write is driven by a unit-test; instead of stepping through the code manually, do it with a test. It doesn't take that much more work to write a test than it does to step through the code.

By writing a test to drive your newly written code, you essentially capture that work; if you manually test the code all that effort just dissipates into the ether. If in, say, six months you or another programmer breaks the code, that test will be there to save you from having to repeat the testing effort. This is how unit-tests protect against regressions!

Over time you will see the benefits of writing unit-tests. One example, you can refactor your code and the unit-tests will tell you if you broke anything.

| improve this answer | |

Start early! Why wait?

Once your system is more complex than a simple "Hello, World!" application, you can start writing unit tests to ensure that what you've coded works correctly. If you use a tool like maven for your builds, you can have the tests run with every build so you should know pretty quickly if newly written code has issues with existing code.

| improve this answer | |

I would use the Test-Driven Development method if I were you.

It's pretty straightforward, you unit test the method before they exist, run the test. They will fail. You will then fix them by making your methods work.

| improve this answer | |

Forget the unit testing. Write and test yourself by being a user. deliberately try to break what you wrote even to the point of doing things you would never do but someone else might. This way you will discover things you could not foresee when writing unit tests. Your unit tests will, like your code make sense, but users are free from such restrictions. Bring in some users often to test as you go. Make sure your instructions are understandable by engaging with users, which unit testing cannot do. create a class or even a function, test it now! Don't move on until you are satisfied it is well done.

| improve this answer | |
  • 3
    Your method can't automatically find regressions for example. If you have automated tests for every bug you fix, then you can say with certainty that those bugs aren't in your program. Other bugs will be, but not those ones. You also have much less assurance that when you refactor you didn't break something. – Tim Seguine Nov 12 '14 at 23:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.