Testing logging to log files

Recommended reading before you read this article: Mockito basics

How do we test logging to logs?

We should not do that in general. The solution might be to test if notifications are being sent to support or diagnostic teams though. The implementation of those notifications might go to logs. For example:

A sample implementation of SupportTeam interface might look like this:

The examples above hide logging behind a SupportTeam interface. This seems to be a good modelling example of the real world scenarios. Who looks at the production logs in the real world? Support team in most cases. Then we should notify support team when exception occurs instead of logging to logs. The implementation of SupportTeam interface can log to logs though. Modelling the real world scenarios is in my opinion one of the key OO principles that people often forget about.

Please comment!

[Removing duplication in tests] (Part 1) Move wiring of objects to class attributes

Recommended reading before you read this article: Mockito basics

Hot to get rid of duplicated code in tests

When we have multiple tests and all of them have similar givens we are tempted to extract those common givens to setup method or the field declarations. This might be a good idea when those givens are just wiring of dependencies. In most other cases it might be not a good idea.
Below I include an example for correct removing duplication of “givens” for multiple tests. Moving wiring of objects in field declarations. This way we do not test the wiring in the test, just the business functionality. The wiring should be tested in acceptance or end to end tests, not on unit level.

The example below also replaces string constants with variable names. For example in the tests we don’t care that the username is “john”. We only care that the username passed around is the same object. So we can move the definition of username out of the test to increase readability.

Please note that all fields are marked as final. This ensures that all wiring was done before we start testing the user object.

Before refactor

After refactor

I have not found any other scenarios for removing duplication in tests by moving common code into set up methods or class attributes. All other scenarios where duplication occurs pointed to problems in production code and design issues. Please take a look at all other parts for further details (coming soon).

Please comment! 🙂

Testing time dependant functionalities

Recommended reading before you read this article: Mockito basics, Fest assertions.

How do we test time dependent operations?

Let us assume we have a report and it may me marked as complete. When it is marked as complete the “completed on” date should be set. The easiest approach would be to do a “new Date()” and assign it to “completed on” attribute.

But how do we test it? We have to take an other approach.
The solution is to introduce a Clock object that can be asked for the current time and which we will be able to mock in tests:

Recommended further reading: How NOT to test drive time dependant functionalities

Starting test names with “itShould” or “should”

Recommended reading before you read this article: Mockito basics, Fest assertions.

Sometimes you might find some people applying a convention of starting test names with a prefix such as “itShould” or “should”, for example:

I used to do it, but now I find it useless. It is unnecessary noise for me. The test name listed below still reads like a sentence (is readable) and has no unnecessary additions.

What do you think?

Pros and cons of TDD

Why do TDD?

  • if you are starting your journey with software development it might be a good path to follow
  • TDD is an effective way of discovering relationships between objects while doing OOP
  • tests document the code
  • it is easier to spot errors and code smells in production code when we have good tests, one just has to seek for simple patterns in the tests
  • there is an increasing need for TDD skills in IT market
  • do it for fun, experience new approach to software development
  • any other ideas? 🙂

When it might not be the best idea?

  • prototyping
  • example: project runs for 3 months and then goes to production only for one month, we might then test only the critical paths through the system
  • sometimes there is no business value in TDD, for example you do a project on you own and you are a very experienced developer, then you might test only the critical paths of the application
  • very little time to release the product, but willing to pay the technical debt and intrest for the technical debt in the future
  • any other ideas? 🙂