Testing web apps is hard work. You've probably found that even the code environment can be hostile to testing, with windows, documents, event listeners, callbacks, and, to make things even harder, each browser vendor implementing the specs their own way. Fortunately, the frontend ecosystem has evolved to a better state, allowing us to even test-drive code that relies heavily on the platform to work.
For this session, we decided to take a randori approach, which is our usual way of doing coding dojos after experimenting with splitting people up into pairs.
The session began with a brief introduction to our plan. The idea was to divide the coding dojo into two parts: in the first part, we would explore the problem we wanted to solve/code and an introduction to web workers; in the second part, we would apply Test-Driven Development (TDD).
The following two sections describe the coding dojo in more detail and at the end of this article we share a few takeaways from this session that you can try on your own.
Part 1: Intro to Web Workers
The first part of the session was dedicated to introducing web workers. This is a well-supported API for the browser, but it is not as popular among developers as it could be.
Web workers offer several advantages, including improved performance for frontend applications. However, they can also add complexity to code maintenance and implementation.
With that example we saw:
- How the render part of the web browser suffers from that, resulting in a poor user experience.
Once we had this done, we started to implement web workers to improve the user experience.
In this part we learned about web workers and the trade offs it offers when implementing a more complex solution. Once we finished we were ready to tackle the second part of the dojo.
Part 2: Test-Driven Development
The second part of the session was all about applying what we learned about web workers in the first part, using Test-Driven Development (TDD).
We started by focusing on the business rule we wanted to implement with web workers. We decided to first implement it without workers, and then refactor it to use workers.
In the process, we encountered one of the difficulties of test-driving code with web workers:
- Since you now have a worker, you need to be extra careful when dealing with resources.
We were able to follow the TDD flow without any major restrictions. In the end, we discussed how web workers are ultimately an implementation detail, and that we could keep the same business logic with or without them.
We were able to learn as a group and better understand web workers. We started with an introduction to the technology and picked a simple problem to code. Then, we moved to a more complex approach and applied Test-Driven Development (TDD) to our workflow.
The main takeaways from the session are:
- We gained a better understanding of web workers. One of the attendees even shared that they thought web workers were more difficult than they turned out to be.
- Web workers can add complexity to web applications.
- It is possible to test-drive code with web workers and refactor to use web workers in code that is not already using them.
The feedback at the end of the session was positive, attendees wanted to see more of those kinds of interactions with new APIs that are available in the browser to be used in our day-to-day work. Given such enthusiasm, we are evaluating new web features that we can fit in future editions of our coding dojos.
Who doesn’t want to learn a new api that can provide a better experience for our users when they interact with our applications? If you want to know more and see what is next, Codurance regularly hosts coding dojos - Take a look at our events page so you don't miss the next one.