When we write automated tests (either unit or integration tests) for our application, we should notice pretty soon that Many test cases use the same configuration which creates duplicate code. Building objects used in our tests creates duplicates
Assertions are an essential part of our unit tests. And yet, it so easy to neglect them. That is a shame because if we overlook the importance of assertions, the assert section of our tests becomes long and messy. Sadly, most tests which I have seen
I am a “testing fanatic” but I don’t understand test-driven development. Or so I thought. I have read a few books and numerous blog posts about it, and all of them have one major problem: The examples are always too simple. Those
Continuous integration has established its place among the good software development practices. However, setting up a continuous integration server and configuring it to run your tests automatically does not mean that you are really doing continuous
Automatic testing and continuous integration have become a some what standard in modern day software development. Even though I have noticed by experience that automatic testing does indeed reduce the number of bugs found from the software, not