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
Every now and then, I encounter some complex legacy code that has been moved around and changed so much, git blame doesn’t help in finding the original commit. Git bisect is the solution here. Why the Original Commit Can Help Sometimes, I read code and (after a while) it becomes clear what it does. But I’m often left wondering why the code is there, what the context was. It allows me to read the commit message and maybe several commits
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
Warning: slightly cheeky post, I have the highest respect for the people behind node-gyp. They’re way smarter than me. If you’ve been working with Node for a while, surely you’ve encountered issues with node-gyp. Searching for the solution can be a frustrating experience. Things get very technical and all kinds of solutions are offered. This is what always works for me. What is node-gyp? I won’t get into the details, because I’m not really bothered with understanding it. I just
AWS CloudWatch allows you to raise alarms when certain values are above or below a given threshold. But what if you want the alarm only when it is between certain thresholds? That’s where metric math comes in. A Simple Alarm In CloudFormation, you can define an alarm quite easily: This will raise an alarm when the amount of requests per minute to the given API goes over (or is equal to) 5000. What if you want this alarm, but a
Here’s a small tip that people don’t often do enough, in my opinion. When developers create some class, variable, or other piece of code that warrants some explanation, many of them add a comment: This is fine if it helps other developers understand what is going on. But it requires them to navigate to the actual file to read the info. One step better is to make these kind of comments available to the autocomplete/Intellisense feature of your IDe/editor: Now
I don’t write about politics on this blog, even though I’m very interested in politics and society. But the death of George Floyd and the ongoing protests make me feel that I should make an exception. Speaking out is the minimum I can do, the minimum I should do. Keep in mind that I’m writing this as privileged person living in Belgium. If you feel any of this is wrong, I’m open for (civilized) discussion. On Police Violence in the
Here’s an overview of all the ways I’ve found to iterate an enum in TypeScript. I was particularly looking for how to iterate over the value of an enum, but still have the strongly typed value, instead of the underlying (string) value. But I decided to make this post about all possible ways I know of. Default Take this enum: Now add this code to log the values: Note: I’m using a separate log function to show what type 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