Today, with various tools and services available, developing applications with WebRTC can be done very efficiently. For example, CPaaS platforms offer a wide variety of features which abstract the complex details of WebRTC away from the developer. This enables developers to build new features very quickly. However, with rapid development, we have a greater need to maintain the code base. Automated unit tests are very good for this purpose and should be written to verify and validate code changes.

You can watch this and other tips from our engineering team as part of our WebRTC Tips by WebRTC.ventures YouTube video series. Or, read on. 

Issues in Unit Testing

Unit tests can have their own issues, as well. One that we commonly see with JavaScript projects is bleeding unit tests. A bleeding unit test occurs when the execution of a test affects the shared state between itself and another test. When running one test at a time, the unit tests pass as expected. But when running the whole test suite together, test failures are seen. 

Bleeding tests may not have their effects seen until a new test is added. In a worst case scenario, some implementation in the application code itself has changed. 

With a larger code base and possibly hundreds of tests, the bleeding test can be very hard to find and resolve. And, the resolution can often be expensive. It frequently requires a refactor of the test — and sometimes of the application code itself. 

Recommended Design Pattern: Factories 

This is where factories come in really nicely for avoiding bleeding unit tests. A factory is an object or function that can create other objects. For unit tests, factories may create models with pre-set data or provide a clear API for setting desired data. When writing unit tests, high test coverage is desirable. Ideally, all known edge cases for a  program should be tested thoroughly. This can be difficult if tests are not written cleanly. Factories make maintaining unit tests easier as they provide a lot of clarity as to what the code is doing. Factories are very expressive and easy to reason about. 

Using factories ensures that resources are created in isolation, shared state is limited, and the common convention of “do not repeat yourself” is easily obtained. When resources are created in isolation, it can be made clear that certain resources are just created for a single unit test. This pattern helps avoid bleeding unit tests. 

For example bleeding tests and their resolution, please refer to our WebRTC Tips Video, Bleeding Unit Tests.

Doing any type of automated testing is an important best practice in software development. It is often hard to do, and particularly hard to do with video applications like we specialize in here at WebRTC.ventures.

We don’t have to build your application in order to help you test it! Learn more about our testing services and let us improve the quality of your live video application.