Sometimes ideas just flow out of nowhere for us. Sometimes though, we get stuck in our head and cannot really seem to come up with anything imaginative. This is the time to get up from your boring desk, find the biggest whiteboard, grab a bunch of colourful pens and get it all out of your logical head. Ideally in the form of a mind map.
If the responsibility of a module or a single class cannot be easily described, then you can be sure that it is trying to do way too much. You should be aware at this point that you are only getting yourself and your team into trouble
Unit testing your software components seems to be a straightforward subject, but .. nothing more misleading. If we do not follow certain standards and principles we can quickly get ourselves and our software into trouble. And, we don't want that, that's for sure.
I am quite sure the Junit 4 experience with parameterisation did leave a bad taste in your mouth. Have no fear, with the Junit 5 coming into the picture we have this aspect covered to the point when it is a shame you do not need to use it for some tests. In this Juint 5 episode, we will take a look at this, oh so crucial feature, and will try to conquer it!
Junit 5 tagging and filtering gives us great flexibility when it comes to inclusion and exclusion of tests during the build phase. Sometimes though we need more fine-grained options as to when a particular test or test group can be executed. Junit 5 gives us the ability to make our tests aware of the environment they are run on and make appropriate decisions based on that.
Ignoring your tests leads not only to the loss of quality but also to something more detrimental in the long run… team morale and its frame of mind.
Read it, close it, do what you need to do, do not tell anyone about it. If there is one single thing that everyone tells you not to do in a unit test is just this: do not test private methods! They are an implementation detail which can change more often than you think. But what if you have no choice and need to mock them?
If the responsibility of a module or a single class cannot be easily described, then you can be sure that it is trying to do way too much. You should be aware at this point that you are only getting yourself and your team into trouble.
