When the testability level of a project is not monitored, it can end up becoming a burden for the software development team. These testability problems usually add up in small steps, making them hard to detect if we do not make the effort to look for them.
Broad assertion cuts out too large a chunk of output and side effects for bit-to-bit comparison, which makes it harmful due to the resulting brittleness. The assertion fails if any small detail changes, regardless of whether that change is relevant to the interests of this particular test. In this article, based on chapter 4 of Unit Testing in Java, author Lasse Koskela explains how to refactor the tests that suffer from broad assertion.
This blog post presents some results of an exploration of software testing tools to discover various types of potential user interface issues even for complex applications.
In this blog post, Alberto Savoia discusses the CRAP (Change Risk Anti-Patterns) code metric. The CRAP metric combines cyclomatic complexity and code coverage by automated tests to help identify code that might be particularly difficult to understand, test or maintain.
This article provides 3 tips to create readable unit tests.
This post tries to summarize the high level basics of writing testable code.
A test is not a unit test if: * It talks to the database * It communicates across the network * It touches the file system * It can’t run at the same time as any of your other unit tests * You have to do special things to your environment (such as editing config files) to run it.
Copyright © 2009-2026 Software Testing Magazine by Martinig & Associates