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 <del>archaic</del> compatible ES5.
I also run my unit tests everytime I hit <span class="lang:default decode:true crayon-inline">Ctrl+S</span> (save).
One library? NO! In JS, at least for browser testing, you need:
- a test runner, like <span class="lang:default decode:true crayon-inline">karma</span>
- a library to actually write the tests, like <span class="lang:default decode:true crayon-inline">mocha</span>
- an assertion library, like <span class="lang:default decode:true crayon-inline">chai</span>
WTF, again? 3 libraries to do something that <span class="lang:default decode:true crayon-inline ">JUnit</span> (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 <span class="lang:default decode:true crayon-inline">setTimeout()</span> 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 <span class="lang:default decode:true crayon-inline ">chai</span> ‘s web page): you can check the test correctness in two ways, the <span class="lang:default decode:true crayon-inline">assert</span> way (like the one used in JUnit), or via a “behavioural” testing definition, something like “<span class="lang:default decode:true crayon-inline ">expect(this).to.be.greaterThan(that)</span> “. two syntaxes for the same thing.
Moral of this <del>story</del> rant
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 <span class="lang:default decode:true crayon-inline">Ctrl+S</span> . 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.