TestJS Summit

TestJS Summit 2021

Nowadays, testing has become the norm. There are many tools available to write different kinds of tests. While tests keep the guard on the main code of the application, how can you be sure that you don’t have bugs hiding in your test code? Should you write tests for the tests?In this lighting talk I will show you a different approach on how you can eliminate certain types of issues from your tests using static code analysis tools like SonarLint or SonarQube. We will focus on common issues found in tests using frameworks such as Mocha and Chai. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Who Guards the Guards? – Finding Bugs in Your Tests 

Hello, everyone. My name is Tibor Blanesi and I work on static analysis as a sonar source. Welcome to this talk, which is called Who Guards the Guards? And I would like to show you three common pitfalls of JavaScript unit testing. So the first issue I would like to show you is the following one. So imagine you have the following test and you write your expectations there. Do you see the issue? Whatever you do inside the expectation, this test actually never fails. Because what is missing is the assertion after the expect. So to have any meaningful testing, it has to look like this. You might be surprised how common this issue is. I will just show you two examples. So the first one is in Kibana project and the second one is in Angular.
The next issue I would like to show you might be a bit cosmetic. However, it often helps to have the clear test to better understand the real issue. So in the following test, when you write your assertion, you always need to provide the actual value, which is the result of the test and your expectations. And the orders in which these values are provided matters. So to the expect, you should provide the result of the computation. And when you invoke some assertion, like equal in this case, it should be the expected value. If you swap it around, you will receive such a message as here, where expected is two and it's supposed to equal to three, which is not a good thing. And it's supposed to equal to three, which is wrong and it might be confusing. Correctly, it should look like this. You should have the addition in the expect call and it should equal to what your expectation is, in this case two, which gives a better message where three is expected to equal the two. So the result is what we computed is three and our expectation was two. And here is the actual correct test where you need to correct your computation to have the test to be green. So this is cosmetic, but when you are debugging more complex issues, it might be really helpful to have a good error message. So here is the real life project having this problem.
You see that in the expectation, the test and data is swapped. 

The third issue I would like to show you in this lightning talk is the following one. Imagine you have a test and this test is going to be always green. Why? Because there is actually no assertion in it. So you are not testing anything. So to fix this test, you should actually assert something. So for example, you want to assert that this string has the value of string. And here is the real life example from ESLint project where you might have this problem. This often happens when you are dealing with exceptions. So the following test will fail if the exception is thrown as the comment suggests. However, the message is not going to be very nice. Better way to do it is to wrap your call in the expectation and assert that either the exception is thrown, or in this case, it would be to assert that no exception is thrown. So this is the documentation from Chai assertion framework, how to do that. 

So you might wonder how you can avoid having such issues in your code. And I will show you a small demo how you can do that with SonarLint or SonarCloud or SonarQube. So first, I will start with SonarLint. SonarLint is an extension which you can install in Visual Studio Code. So here is the extension, it's already installed. And here I have the three examples I was showing you. So the first one here is the incomplete assertion where the expectation contains the comparison between some function and the result value. And actually, to have this test, to make it more meaningful, what you should do is to remove the expectation from here and add the assertion like this. And the issues here disappears. The second problem I was showing where you can hover here over the squiggly line to see the description. So it says that the two arguments in the assertion should be swapped, and the correct order is the actual value first, and then your expectation. So when I exchange the arguments, the issue disappears.

And the last problem I was showing was the problem with the missing assertion. So you see here over the squiggly, when I hover over the squiggly line, I see that at least one assertion should be in this test. So let's add an assertion here. So let's say we expect the string to be empty. Like this. And the issue disappears. So this is how you can quickly fix it in your IDE, and your editor will notify you when you have this problem.

And also, if you want to integrate this sort of static analysis testing for your unit test in your continuous integration pipeline, you can use SonarQube, which you install on premise, or if you prefer the cloud solution, there is SonarCloud. So they will both look the same. Here I have the SonarQube, and here is the same file which was analyzed in the continuous integration pipeline. So here you see, again, the squiggly line where the issues are located. So this is my lightning talk. Thank you for your attention, and goodbye.

Tibor Blenessy

DevOps.js

DevOps.js Conf 2021

CI/CD pipeline became the norm in software development. So is linting, which is a basic form of static analysis. In this webinar I would like to demonstrate how you can go beyond simple linting and improve your pipeline to provide additional insights into your code and allow you to deliver more reliable and safe applications. Prerequisites:Familiar with CI/CD concepts. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>