Automatic tests with TestCafé and NUnit - TechBlog
In a previous Xuntos Tech Blog, we wrote about the technology stack that keeps one of our applications up and running for hundreds of users at the same time. Today, we'll discuss how to ensure the quality of applications by creating tests that can tell you at the touch of a button whether the application does what it should do. We talk about this with Joost, who is working full-time on building and refining these tests during his internship.
Startup
Joost starts talking about how he started his internship at Xuntos:”The Hague University where I study HBO ICT, has an internship bank where Xuntos is enrolled. I wrote to a number of companies that I found in that bank and Xuntos was one of the companies I was allowed to meet with. During that conversation, the topic came up with the assignment that I was going to do. Together, we decided that I would improve automated tests for one of Xuntos's applications. That seemed really fun and challenging, after the assignment was approved by my internship supervisor, I was able to start writing the first tests in September.”
Test Cafe
After that, Joost continues about the start with Test Cafe: “My colleagues had already built a number of tests with TestCafé and I was going to expand and improve them during the first part of my internship. TestCafé is a tool that can be used to develop end-to-end tests for an application using TypeScript. You can write in code “click on this button and then enter the following text in this field” and you can check the application's response.” He proudly says that it's “Very cool” to see that TestCafé can do all the things a user would do automatically.
Setting up the tests
Joost then talks about his way of setting up tests: “I often took up making tests by taking a good look at the user interface of the application. If I saw a button, link, or form that I hadn't tested yet, I wrote an empty test with a descriptive title. Then I was able to go through all those empty tests later to work them out one by one. This often consisted of writing the happy flow first, so a test where everything is done as it should, then I started thinking 'how can a user do this wrong and how should the application respond? '.”
He proudly gives an example of how he found a bug with this: “For example, the application has a search field that allows you to search through things. I was wondering what would happen if a user pasted emoji into that field, so I wrote a test where I had TestCafé paste three smileys into the field. There is not a single item in the application that has emoji in the name, so I expected that there would be no results. However, there were over forty of them, so the test failed.” After raising this with his colleagues, Joost received the green light to solve this bug himself.
Maintainability improved
“When I started, some tests had already been made, but these existing tests were not designed to be maintainable. For example, each test separately defined which HTML elements should be used. This is not useful, because if something changes on the screen, you have to adjust your tests in many places,” he says when talking about the things he learned about TestCafé. “It's much better to make a model of a page where you define all the different buttons and fields as variables. Then you can use those variables in your tests, if anything changes to the page, all you have to do is change that variable and your test will work again.”
“The login details were also included in the code. Of course, that is not the intention, although you do need login details to test the application. To do this, I created a test runner that, when running, first asks for the login details you want to use, then runs the tests with that data.” Joost also talks about the two different versions he made for this: “First, I wrote that test runner as a BATCH file, which worked great for me. Until a colleague with a Macbook wanted to run the tests. Because a BATCH file only works on Windows and not on macOS, then I created a new version written with Node.JS. It works for everyone.”
Backend unit tests
“After about half of my internship, I continued with the following part: Writing unit tests with Unit. Where TestCafé uses TypeScript, I do this in C# because the backend is also written there.” Joost states that he found this difficult at first: “The backend of the application is quite complex and then finding a starting point was quite a challenge. The interaction between the controllers, services and repositories dazzled me a bit, especially when combined with the fact that I had to mock them all.”
Moq mocks
Joost explains that a unit test should stand alone: “If you want to test a method with a unit test, that test should not be dependent on databases or external services. For that, I make use of the framework MOQ, that allows me to make mocks of all services and repositories. Mocks are a very smart concept. You're actually saying to the piece of code: “If you need ServiceA, I'll give you MockServices”. That MockServiceA has the same methods as ServiceA, but then you can determine exactly what it will give back. So you don't have to use ServiceA, but your test can pretend it's there anyway. This makes the test much more reliable, so you can also test what the code to test as a result of the service is something really crazy. Without mocks, you'd have to do all kinds of setup for that, but with a mock, you can just specify what to give back.”
Joost says that he needed a number of tutorials to understand that, but that he is now well on his way to doing it. “I'm also starting to understand much better how the application works, just testing the code is a bit more abstract than TestCafé, but no less fun. Especially not when I can find bugs because of it.”
Coverlet
“One of the other things that makes it fun is the code coverage,” says Joost enthusiastically. “I have the tool Coverlet installed in the test project. This is a test collector, a piece of software that collects the results of the unit tests and records them in an XML file. That XML file can be used to generate a report that tells exactly which part of the code is being tested with the unit tests. He does this by means of a percentage, but also even at the code line level. In such a report, you can even see if statements show whether all the different conditions are covered by the tests that have run.” When asked if there is a certain goal in terms of code coverage, he timidly replies: “Not really yet, but the main thing is that the tests that are available are of high quality so that you can count on them.”
Finally, we ask Joost if he would recommend an internship at Xuntos to his fellow students. “Yes, provided they love web development. There are great colleagues and a good company culture.” Are you also looking for a (graduation) internship? Then contact us for a cool and interesting assignment.
~ Joost was interviewed by Victor Remmerswaal
Heb je vragen? Of wil je samen sparren?
We denken graag met je mee hoe jouw organisatie digitaal kan versnellen. Of het nu gaat om een UX, technische uitdaging of AI oplossingen. Stuur een berichtje en we nemen zsm contact met je op.
Verder lezen
Nieuwsgierig? Lees onze andere inzichten over webontwikkeling, AI, toegankelijkheid en digitale strategie
.jpg)
