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
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!
I’ve written about Property-Based Testing for .NET previously. It’s a way of writing unit tests with random (but constrained) inputs. This means your tests are run multiple times with different inputs and your code is tested more thoroughly. You might even find bugs you didn’t know were there. As I’m working quite a bit with TypeScript these days, I decided to look into property-based Testing with TypeScript. At my current client, we use Mocha for our unit tests, so let’s
If you’ve been following this blog for some time, you know I develop software mostly using test-driven development AKA TDD. But while this mostly means unit tests, it shouldn’t be limited to only unit tests. At one of my current clients, we use AWS Lambda functions written in TypeScript. These are (usually) relatively small blocks of code that can be invoked by a HTTP call. The function has a very limited scope of what it can be used for, i.e.
This post was written for the NCrunch blog. You can find the original here. Unit tests help developers write better code and provide a faster way of getting feedback compared to testing manually. But unit tests are also another piece of code that must be maintained and taken care of. Unit tests can become a mess just like production code can. Here are some tips on how to improve your tests and avoid such a situation. Keep Your Tests Small
This post was written for the NCrunch blog. You can find the original here. There are many ways of testing your application or library. The test pyramid provides a good starting point to the most common types of tests—unit tests, integration tests, end-to-end tests, and manual tests. But there are other types of tests, like contract tests, load tests, smoke tests, and what we’ll be looking at in this article—property-based tests. What’s the Idea? Property-based testing is where you test
This post was written for the NCrunch blog. You can find the original here. Test-driven development is a technique to drive the development of your project. TDD enables you to verify your code, it provides confidence for refactoring, and it enables a cleaner architecture. But what if you already have an existing codebase that wasn’t developed with TDD? How can you get started with TDD in such a (legacy) project? There are several approaches to this, so let’s dive in! The Situation