Skip to main content

Posts

Showing posts from July, 2015

You Still Need Manual Tests

This blog has numerous examples of why unit, integration and contract testing is essential. However you still need manual tests. It is foolish to believe that all testing can be covered by automated tests despite the bias in this area.Why?Manual tests can catch anything you may have missed at an automation level.Manual tests can be unique. Use exploratory testing to try different scenarios.Manual tests that fail become automated tests, so they can never regress.Manual tests exercise the full stack. Many areas such as DI conventions, logging, and other framework related configuration are better suited to manual verification.UI changes require visual verification - automation is near impossible here.More Than Just FunctionalityOver the years, manual testing has caught numerous bugs, issues or things I've just plain missed. When you are deep in a problem it can be hard to see the wood for the tress. A second party manually testing provides an unbiased check of your code for a second …

The Benefits of Contract Testing

I previously claimed that you need some integrated tests but as few as possible. There are huge benefits to this approach, but there is a problem. How do you stop your test doubles falling out of line with the real implementations? The answer is to use Contract Tests.StepsCreate a base test fixture, this is where your tests live. All assertions belong here.Subclass this base class with each implementation.Override each setup step to provide the implementation that is to be tested.All tests should pass for each instance.ExampleIn this example there is a SQL repository and an in memory repository. It is not possible to change either in any manner that causes them to behave differently. We can safely use the in memory repository for tests, with confidence that the test double matches the contract of the real implementation.The test double implementations can be executed on every test run. While real implementations can be relegated to execution prior to commit or during continuous integr…

Integration Tests

It is well documented you need a balance between different categories of automated tests. The split is usually in the form.70% unit20% integration10% acceptanceWhile unit tests make up the majority of tests, there is a limit to their effectiveness. As soon as you leave the system boundary you need integration tests. Examples of when integration tests are required is code that interacts with databases, web services or the file system.These integration tests should not test logic, this is a mistake. They will become brittle and slow to execute otherwise. Instead of checking domain logic, test at a lower level. Go as low as you can without leaking implementation details of the subject under test. By going as low as possible you will radically reduce the number of integration tests required. Less tests means easier maintenance. Less tests also means faster tests.ExampleAssuming a SQL database, invoke the repository and test as lightly as possible. Do not indirectly test this repository by…

Static Code

Static code is considered a bad thing by developers. This is especially true when working with legacy code. The use of static code is often seen as a smell and should not be used.This is not as black and white as it first seems. Static code can be problematic when global state is involved. Not only is it hard to change, static code is very hard to test in an automated fashion. Bad examples of static code include persistence, third party services, and out of process calls. These examples should avoid static code where possible.One guideline that served me very well in my early days of TDD was treating static code as a death to testability. Unfortunately some developers don't move on from this guideline and treat any use of static code as bad.In fact static code can have a benefit. If a method within a class can be promoted to a public static method (PSM) it shows that the code is stateless. This allows the "extract class" refactoring to be performed. Without a PSM such re…