test | imalittletester

When automated test are running, they are either running on your own machine (when you write them or run them to check something), or in your CI.

When you run the test on your machine, if there are failures, it might be easy for you to look at what is running (if you have some visual tests, that interact with either browsers or apps on your machine). You can just rerun a failed test and visually inspect for failure reasons. But, if tests are running on a CI machine, visual inspection is either very difficult or even impossible. You might not have access to connect to that machine, or to see how tests are being run. Continue reading Test design: write tests with proper console output to easily identify failure reasons →

When i look at a test class, what i want to see is clean code. What i mean by that is, well a few things, but the most important one: i want the test class to hold the code for the tests, not the code for everything but the kitchen sink.

When we write tests we have a lot of data to prepare for them. Whether this is the ‘expected’ or the ‘actual’ data used in the tests, or some auxiliary code that we need, there always is some processing that needs to be done, apart from the actual asserts that a test should do. What the test class should contain is only the checking / asserting part, while having specialized classes generate all the data that is required in the test. A test class should only check the actual data against the expected data. This is the separation of concerns principle. Continue reading Write clean code for your tests by using the separation of concerns principle →