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
I’ve sung the praise of TDD/automated testing many times before, but recently encountered an angle I hadn’t considered yet: the importance of automated tests for onboarding. Automated tests have several benefits: if you’re practicing TDD, it generally drives your design in a good direction it provides a safety net for refactoring it can catch bugs it speeds up development it provides some documentation for your code But here’s another advantage: it helps new developers tremendously. In part, because of the
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
I’ve recently been adding Knockout to an ASP.NET MVC application. I would consider Knockout a previous-generation solution and would prefer to use a full-fledged SPA framework like Aurelia, but that’s a bit out of scope for the moment. After introducing Knockout, I wanted to add unit tests on my viewmodels with Mocha. I had some trouble at first, and read quite some answers on StackOverflow that claimed you need a browser. Because you’d want to run the tests from a
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