Anything that can go wrong ... needs to tested

Building web applications with the Web Audio API and other related APIs is very approachable. A browser is most likely already installed on any computer and projects can be started directly in the browser using online IDEs. But converting such a prototype into a robust and reliable application can be very challenging. The ubiquity of web browsers has the downside that there are endless combinations of browsers at different versions on different operating systems. The fact that a website is just a link away and doesn't need to be installed is great but it also means that loading one of the critical files might fail. There are many things that can go wrong. Most likely it's just a matter of time until they actually go wrong at least for some of your users. Luckily there are ways to test web applications and all the parts which they are made of. This talk will give an overview of various techniques that can be used to make sure anything that can go wrong is covered by a test. Due to the limited time it won't be possible to explain everything in detail but this talk will hopefully be a starting point that can be used as a resource when struggling with how a certain behavior could be covered with a test. Of course testing the code for formal correctness is a good start. However when building an audio app writing efficient and performant code is very important. Browser engines constantly evolve and therefore performance characteristics change frequently. That's why it makes sense to test the performance of critical code. It is for example possible to test two or more versions of functionally equivalent code to verify which version is the most performant. Audio apps do also tend to run for a long time. This means that memory leaks have a very negative impact on the overall performance and should be avoided. It's possible to verify that a piece of code doesn't leak any memory with a test as well. Currently there are only three main browser engines but still there are a lot of different browsers which are based on modifications of those engines. Most of those derivatives modify the browser APIs in interesting ways. Brave does for example patch the Web Audio API to prevent device fingerprinting. Especially on smart phones many apps open links with an in-app browser that has limited capabilities. It's possible to test these scenarios with automated tests, too. Even though the currently used browser might have all necessary capabilities to run your app it's still possible that the usage of some APIs is blocked by the user. It's even possible that a user revokes some previously granted permissions at any point. Luckily most browsers support testing these scenarios as well. Because a web browser can be installed on a smart watch or a maxed out gaming computer it's very well possible that the device can't handle the desired workload. This might even happen on a reasonably fast desktop computer if it simultaneously runs a lot of other software. It's therefore important to have a strategy to deal with limited resources. And of course it's important to test this, too. Last but not least your app might rely on external devices like some special audio hardware or MIDI devices. Testing this in an automated way with real devices is tricky but mocking devices in automated tests can be done. Anything that isn't yet covered by a test will eventually throw a runtime exception. Tracking those is the first step towards fixing them. Additionally they can be turned into a test case which makes sure the same bug doesn't need to be fixed twice. And finally there is a way to ensure bugs caused by browser regressions don't surprise you by testing your code in the upcoming version of browsers. The list of possible testing strategies is very long but I'm sure there is more. I would love to trigger a discussion at the conference to talk about techniques used by others as well.Talk pape