Never written much unit tests, how can I practice more of it?

Question

I have an interview coming up soon next week and there's a few things on their list of responsibilties for this software development job (the job position title is vague, it says java developer) that I am worried about:

• Unit test features
• Debug new features
• Provide recommendation on test case design (what is this?)

I am worried because in my past software projects, I have not bothered writing unit tests. I know how to use JUnit to write tests in Eclipse and the process but it's just that I have not much experience writing tests. For example, I rely on data from the web, which varies a lot from each other, and process this data. How can I write test cases for every single type of data? Also, if the data is from a local database, how would I write a test case that checks that data from tables are being read properly?

I've used the debug feature in Eclipse whenever I could, but sometimes, when I am accessing a library which doesn't come ith source code for (e.g. commercial 3rd party Jars), the step into feature would stop. So for most cases, I just System.out.println to discover where the bug is happening. Is there a better method?

How can I practice in the short period of time to be somewhat competent in writing unit test?

Answer 1

The only way to practice is to just do it. I'm still learning how to write effective unit tests myself. Unfortunately, you need hours behind the wheel to get true feeling for what good unit tests looks like. The only shortcut I could think of is working 16 hours a day instead of 8 and you'll learn twice as fast, but only until fatigue sets in.

Few things I'd suggest:

• Make sure you are working on a task that is not time critical. Time pressures and the feeling that you must be done right away, is what typically causes people to take short cuts and either a) not produce any tests, b) produce very little or c) produce tests which are very hard to maintain because you never took the time to refactor them.

• Approach the task of writing unit tests with the same requirements for code quality (if not more strict) as you would production code. Some people think that unit tests are not being released, so it's not as important to follow good practices and then they end up with tests which are very fragile and extremely hard to maintain.

• Allocate enough time to not only write the test but also any helper classes that would make yours (and others on your team) life easier. From my own experience, it seems that people tend to take shortcuts when writing tests because certain tasks are too long to code properly and because it takes even longer to factor code out into a library, they end up copy/pasting code between unit test projects. I started a unit test helper library for our group with the intention that it would speed up development of future tests (some common functionality in the library: simple code for recording/verifying mock object actions, code for working with files to help unit tests which need to feed external data, standard hooks to override win32 calls...).

• Get into a habit of practicing TDD where you write tests before the code. At first it seems like unit tests are a lot of overhead, but since you must exercise the production code you've just written anyway, TDD more than makes up for it because it becomes incredibly easy to verify functionality of the production code so even when not considering all the long-term benefits, it will immediately start paying back the time it took you to write the tests.

This outlines how to learn to write good unit tests. If you want to simply "know" what a good unit test is, there's a number of really good books out there. (I'd start with The Art of Unit Testing)

Answer 2

Create a simple class and write unit tests for it. Only through practice will you be able to understand how it is done. If necessary, find examples of unit tests in open source projects or refer to some online tutorials for guidance.

Good luck on your interview!

Answer 3

The software community is divided on the matter of unit tests.

I recommend that you don't write unit tests, they are mostly useless. They are written because "it's good practice", "mature teams/developers write unit tests" or some other industry dogma.

Integration or end to end tests are on other hand a sign of the team really caring about quality.

Anyway, let's get to some specific points of your question.

1. Writing tests for code which accepts data from the web.

Start with happy path test case. This test is there to show that the code works in its basic scenario. This is super useful to validate that your code changes didn't break the app in a major way.

If the logic accepting data is complicated write happy path test for all major branches of this logic.

In my experience this test pays for itself very quickly, usually within hours after it's written. Believe me, this test just keeps on giving.

Then you can write a test which proves security works and that your API returns 401/403 when appropriate.

After that, write tests with data which misses required fields. In a lot of cases you can write the code for it once and execute it with different missing field.

2. Test data

The purist way to write tests is to write them in a way that they create all data necessary for the test and then delete all that data after the test. In practice this is often not possible and one popular strategy is to flashback/restore the db regularly (e.g. once a day, or every time you run the tests).

Database tests will often assume some baseline data is present in the database - this is OK.

3. Printing for 'debugging'.

It's 2016 and debugging is easier and easier but I believe that adding lines to logs is still the way to go when you cannot step through the code.