There’s a Catch-22 hidden in the arguments that many people use to rationalize not writing tests. The Catch A Catch-22 is a situation that you can’t escape out of due to contradictory rules or limitations. In case of automated tests for software, the arguments often go like this. At the start of the project, both developers and managers say that the project is too young and changing all the time. There’s also market pressure to get something minimal out there
A while ago, I did a webinar for TypeMock about unit testing legacy code. It’s about why we want to unit test legacy code, the advantages and disadvantages, and it includes some minor live coding using TypeMock’s Isolator tool. You can watch it here: I hope you like it. Let me know what you think!
This post was written for the NCrunch blog. You can find the original here. When you dive into automated testing and test-driven development, it won’t take long before you learn about the testing pyramid. If you’ve never heard of it, don’t worry. I’ll explain what it is first, then go into some variants, and finally explain how you should use it as a guide toward a quality test suite. What Is the Testing Pyramid? Mike Cohn first came up with
This post was written for the NCrunch blog. You can find the original here. In 2018, just about every developer has at least heard of test-driven development. But that doesn’t mean every team is doing it or that every project has an extensive suite of tests. It doesn’t even mean everyone likes it or believes in it. Join me as I start out with some basic facts that no one should be able to deny. From there, I’ll work towards
This post was written for the NCrunch blog. You can find the original here. I once worked at a client site where the technical lead told me not to waste time writing tests. Speed was important and writing tests was a waste of time. Besides the fact that that’s a fallacy (I write code better and faster when I include tests), it also implied I needed his permission to write tests. And it wasn’t a good time for writing tests.
This post was written for the NCrunch blog. You can find the original here. When you first start writing unit tests, all is well and the few tests run in a matter of seconds. After having written hundreds or thousands of tests, running them might take…long. Too long. But when is long too long? How long should your unit tests take to run? And how can we reduce the time it takes, without removing or skipping tests? Why Do We
A while ago, I had to explain, not for the first time in my career, why using interfaces, having loosely-coupled code, and writing tests (first) is a good idea. Time and again, I find developers, teams and companies resisting certain ideas that have been around for years or even decades. One of the reasons often stated, is novelty. An idea, principle or technology is refused because it is new and who knows what the next thing will be. Better to
I always try to convince other developers that writing your test first is not just about doing TDD the “correct” way (if there even is such a thing). That sounds a little fundamentalist. Rather, it’s about making sure your test is failing and failing for the right reason. Actually, this is only one reason, as writing your test first also pushes you more towards writing only the code you need, writing tests that cover all code paths, and forcing you
When writing tests, you can often end up with tests that have (almost) the same setup. Certain input variables may change, but the structure of the setup code remains the same. When the setup is small, you can copy from one test to another. But when there is more ceremony involved, you will start to feel the need to avoid duplication. It’s a best practice to apply coding principles to both your production code and your test code. Don’t repeat
Continuing on my previous post on WebAPI, Autofac and filters, I now want to add an integration test. Unit testing WebAPI controllers is no different than testing other pieces of code. Just inject mocks in the constructor and you’re good to go. Integration testing can be as simple, if you’re not using filters. The filters can, however, add interesting behavior to your controllers, like the exception handling I explained in my previous post. To fully test this, you will have