This post was written for the Testim blog. You can read the original here. Cucumber.js and BDD aren’t new kids on the block. But they’re still fairly unfamiliar for many developers. That’s unfortunate, because the two can be very powerful tools for both the business people and developers. Let’s have a short look at what BDD is, and then see how Cucumber.js can be used to your advantage. What Is BDD? If you’re unfamiliar with BDD, don’t worry. It’s not a difficult topic.
This post was written for the Testim blog. You can read the original here. Looking to test your JavaScript and/or TypeScript code? Then you could do worse than go for testing with Mocha and Chai. These two libraries are among the most popular tools that developers use to write tests for JavaScript or TypeScript code. But if you’re not familiar with them yet, let me show you how easy it is to get started. Introducing Mocha Mocha is a unit testing library that
This post was written for the Testim blog. You can read the original here. There are many libraries available to write unit tests for your JavaScript code. One popular option is QUnit. Let’s look at how you can get started with QUnit. But let’s not stop there. Measuring code coverage of your tests is a useful metric to gain insights and improve your test suite. We’ll open the tutorial with a brief overview of QUnit itself, so we’re on the
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