While working on a legacy application for a client, I wanted to get some code coverage for my tests. In Python, this usually means running Coverage.py and pointing it to your unit tests. This being a legacy application, there were no unit tests. There were Postman tests however. This is a simple technique that is useful when working with legacy applications. The idea is simple: we run our application using Coverage.py. The application is a Django application and so it
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