Testability is a topic that has always been a bit problematic in the javascript world; mainly because there are a lot of inexperienced programmers using it as their first language and because it has a history of people copy pasting fragments around on web pages.
There are plenty of tools to write tests for javascript but frontend js has this tendency to turn into an untestable mess and there is this misguided concept that it is simply impossible, or worse, redundant. One problem is that people focus on the wrong type of tests and don't understand the difference between unit and integration test. You see people trying to run scenarios against a mock that basically fires up the whole application. This is a lot of work and those tests can be very brittle. I've talked to many engineers that got all excited about the prospect of their test library firing up a headless browser; just so they can test the side effects of events on lambdas on the dom. Don't do that. It's stupid. Make your side effects unit testable and you don't need a browser, or a dom.
Unit testing is where the action is. Unit testing is very straightforward provided your code is testable. This requires inversion of control. Any time that you have code that initializes stuff as a side effect of being used, or imported, you are creating a testability problem. You can no longer consider the unit in isolation since it fires up stuff that fires up more stuff, etc.
Lambda functions make this even worse. Now you have a class with a constructor that constructs other things than itself (simple guideline: constructors must not do work) and then inserts lambdas in those things that do the actual things you need to test. All inside a constructor that gets called from another constructor. Add promises to the mix and you have a perfect horror show of asynchronous side effects of a things being created that may or may not fire events, etc. Simulating all of that in a unit test is hard. This code is effectively hard to test.
Another problem in many javascript projects is the (ab)use of global variables that are accessed from all over the place. Magic elements in the DOM, a library declaring a const with a singleton instance (aka. a global variable) for which the reference is hardcoded everywhere, magic elements in the DOM that contain data that are passed around via imports. These are problems you have to work around when writing a test when you might want to have an alternate value.
The way out is simple: design for testability. IOC is one of several tools you can use and a crucial one but step 0 is acknowledging that what some people claim is elegant is in fact inherently untestable and therefore something needs to change.
Hi! I am a longtime developer with a passion to empower other developers to be their best. I focus on cloud development and everything related to data access from .NET and .NET Core.
Thank you for this insightful reply! It makes a lot of sense. I would also add that doing testing the right way (and not just to check a box) transforms the way developers approach code. It's like words: tough for a toddler to communicate with only a few, but an adult can convey very complex thoughts by using the right words as building blocks. Having a test-conscious approach and leveraging patterns like IoC improve your "developer vocabulary" and helps simplify the expression of code.
Testability is a topic that has always been a bit problematic in the javascript world; mainly because there are a lot of inexperienced programmers using it as their first language and because it has a history of people copy pasting fragments around on web pages.
There are plenty of tools to write tests for javascript but frontend js has this tendency to turn into an untestable mess and there is this misguided concept that it is simply impossible, or worse, redundant. One problem is that people focus on the wrong type of tests and don't understand the difference between unit and integration test. You see people trying to run scenarios against a mock that basically fires up the whole application. This is a lot of work and those tests can be very brittle. I've talked to many engineers that got all excited about the prospect of their test library firing up a headless browser; just so they can test the side effects of events on lambdas on the dom. Don't do that. It's stupid. Make your side effects unit testable and you don't need a browser, or a dom.
Unit testing is where the action is. Unit testing is very straightforward provided your code is testable. This requires inversion of control. Any time that you have code that initializes stuff as a side effect of being used, or imported, you are creating a testability problem. You can no longer consider the unit in isolation since it fires up stuff that fires up more stuff, etc.
Lambda functions make this even worse. Now you have a class with a constructor that constructs other things than itself (simple guideline: constructors must not do work) and then inserts lambdas in those things that do the actual things you need to test. All inside a constructor that gets called from another constructor. Add promises to the mix and you have a perfect horror show of asynchronous side effects of a things being created that may or may not fire events, etc. Simulating all of that in a unit test is hard. This code is effectively hard to test.
Another problem in many javascript projects is the (ab)use of global variables that are accessed from all over the place. Magic elements in the DOM, a library declaring a const with a singleton instance (aka. a global variable) for which the reference is hardcoded everywhere, magic elements in the DOM that contain data that are passed around via imports. These are problems you have to work around when writing a test when you might want to have an alternate value.
The way out is simple: design for testability. IOC is one of several tools you can use and a crucial one but step 0 is acknowledging that what some people claim is elegant is in fact inherently untestable and therefore something needs to change.
Thank you for this insightful reply! It makes a lot of sense. I would also add that doing testing the right way (and not just to check a box) transforms the way developers approach code. It's like words: tough for a toddler to communicate with only a few, but an adult can convey very complex thoughts by using the right words as building blocks. Having a test-conscious approach and leveraging patterns like IoC improve your "developer vocabulary" and helps simplify the expression of code.
I think the biggest thing we need to change is to stop using invaluable time writing Unit tests. A Gigantic waste of time.