Trying to write this post as a 2007 blog post: personal, not so politically correct. (I’m not involved in JS politics by the way)
I was pretty wrong. Browser apps are everywhere.
Everybody talks, nobody really does it: TESTING
nobody really does testing
WTF? I have heard this from people that I respect, and at many companies where I was interviewed. Why?!
Our apps are not so big that you can’t test them manually
Well, this can be an explanation, but not a great one.
Uhm … we are reaching the point …
Now that’s the truth, ol’ boy. Let’s dive into it.
My personal testing jurney
What about Gulp? Gulp is a build tool that can do a lot of stuff for you. I use it to trigger actions everytime I save a file, like running a syntax checker and convert my ES6 code to more
archaic compatible ES5.
I also run my unit tests everytime I hit Ctrl+S (save).
they were the first result on Google they worked at the first attempt.
One library? NO! In JS, at least for browser testing, you need:
- a test runner, like karma
- a library to actually write the tests, like mocha
- an assertion library, like chai
WTF, again? 3 libraries to do something that JUnit (for Java) does alone ?? This is an example of the over-populated, github-based, quality-variegated NPM package manager.
These 3 pieces of software still don’t have many years of maturity on their shoulders, and are not immune to bugs (which are promptly resolved, however). I have found one in mocha, for example, and I could not figure out until I upgraded.
Once you understand how to use these three libraries, then you have to actually write tests for your application: I don’t have words to describe how difficult is to test a function that uses multiple setTimeout() in the code (it’s an audio player, and deals with timing…). And now my next step in this journey is to mock stuff.
Another discovery I want to share with you (well, it’s not a discovery, since it’s on chai ‘s web page): you can check the test correctness in two ways, the assert way (like the one used in JUnit), or via a “behavioural” testing definition, something like “expect(this).to.be.greaterThan(that) “. two syntaxes for the same thing.
Moral of this
Should it be this difficult to test stuff? No.
So, if you believe that your application will be refactored some time in the future, if you don’t want to become crazy, test it. Test it now. Run tests every Ctrl+S . This is the only way to be sure that things will not break up. Js is a dynamic language, it’s not statically typed, and IDEs do not do type checking for you. Help yourself with testing.
And finally, when testing will be cool again, you can say you were already doing it when stuff was being developed. You can talk like a good, ol’ Testing Granpa.