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.

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!

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.

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.

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.

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.