Other awesome posts in the series: If the code we want to test is highly-decoupled from its dependencies, we probably don’t need to do anything to it. But when we have a medium-big ball of mud things change. There are parts we want to ignore or control through mocking, and Read more…
It used to be. Somewhere, squeezed between the end of development and release. But then things changed, because they had to. We’re testing product ideas, way before there’s one line of code. We’re testing the code as it’s being written, because we want to make sure it does what we Read more…
When we talked about understanding what we’re actually testing in error handling, we talked about the ability to understand the behavior of our code-under-test . Just to recall, here are the three types of error implementation, and what we can check: No error handling – Any exception is handled somewhere Read more…
One of the things that unit tests are best for is checking error conditions. While we want wider coverage of full happy flows, error conditions are sometimes hard to simulate in a big system, and unit tests excel at minimal setup to make sure our code handles the problem correctly. We have Read more…
Other awesome posts in the series: So we talked about static constructors and how to go around them. How about instance constructors? Are they innocent or guilty of the same crimes as their static brothers? I think Java got the terminology right (although not the implementation). What we call a Read more…
The other posts in the series: Where we last left off, we discussed how to dismantle the static constructor (or initializer) booby traps. And I promised you an example. I’ll do that in C#, but the operations apply to any language that uses these constructs. Before I do that I’ll Read more…
Here is the rest of the gang: This time we’re going to tackle the most problematic issue in testing object-oriented languages. Obviously because constructors only exist in those, but also, because even power tools have problems handling them. But we’ll start where it hurts less. The evil static constructor Static constructors Read more…
Each stage of implementation is hard in its own way. When we start out with a new effort or process, we think of it as: Sure, it will be hard in the beginning, but it’s going to become easier as we continue. It’s true, and then after a while a new challenge Read more…
Kevlin Henney asked once: Why do cars have brakes? Imagine if cars didn’t have brakes, how fast would you go? You’ll be driving really slow to not hit anything. But by giving the capability to slow down, brakes actually give us the ability to go faster. TDD is like a Read more…
