Getting Started in JavaScript Testing

A (brief) overview of JavaScript unit testing.

Transcript

1. TESTING YOUR JAVASCRIPT A summary of the current testing landscape, the different kinds of tests, and where we can start for automation.
2. WHY UNIT TESTING? "Wait, so I have to write more code for the same module?" Tests are part of what we do, no matter what. In lieu of unit tests, you are probably refreshing a page (or several, if you're working on a global component. . .) to verify that your changes didn't break the world. And let's be honest, sometimes we're in a rush and don't even check everywhere that we should.
3. MAGICAL BENEFITS! Okay, not magical. But still pretty cool: Automated testing! Accountability! Know precisely when your code stopped working! Improved code quality! Because you're planning out the structure before you write a line! Onboard your fellow devs (or [ugh] vendors!) with the confidence that you've documented and tested out your ideas, and they work. Cover yourself when the vendor breaks things! ("Hey buddy, it was working when I gave it to you, see?")
4. "THIS IS GREAT BUT . . ." ". . . Won't it take more time? When will we have time to write and maintain these tests?" Yes, but you're saving time elsewhere (See: Magical Benefits). Initial setups for your module can be handled by a smart generator ( , etc.), and once you get the hang of it it really isn't that much extra effort. The bigger question is, how much time are you losing for untrackable issues? How much time does it take to manage poorly-written code that has no tests to back it up? (HINT: IT IS A LOT) Yeoman.io
5. TDD VS. BDD First, what is Test Driven Development? [F]irst the developer writes an (initially failing) test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. http://en.wikipedia.org/wiki/Test-driven_development
6. BEHAVIOR DRIVEN DEVELOPMENT For the F o o M o d u l e , when I activate the navigation, C o o l I n t e r f a c e B a r should appear. (Or something like that) Behaviour-driven development is about implementing an application by describing its behaviour from the perspective of its stakeholders. d e f i n e ( ' F o o M o d u l e ' ) w h e n ( ' T h e n a v i g a t i o n i s a d d e d ' ) e x p e c t ( c o o l I n t e r f a c e B a r . v i s i b l e ) . t o B e ( t r u e ) ;
7. WHAT MAKES A UNIT TEST? Broadly, you should start by describing what your module does. Each small bit of that description becomes a specification (thus a test), and will correlate to a method when you actually write the class.
8. WHY WRITE TESTS FIRST? Writing the tests establishes that you know what it is that you're building, what you've promised, and what you'll deliver. It shows what you have yet to implement. It makes you consider the module's architecture before you jump into code.
9. WHEN DO I CHANGE MY TESTS? DO: Update your tests if QA reports a bug showing that you missed something. Your code will then fail again, until you fix it to meet the updated test. DO: Add new tests when you realize you missed a feature, or when a new feature is added to scope. DON'T: Change the tests to make the code work. If you change your mind about architecture, change the tests first, and then edit your source so that it passes.
10. TESTABLE JAVASCRIPT Before you can write unit tests, you need testable code. Easier said than done. Testable code is properly organized, non-complex, and modular. A fantastic article on writing testable JavaScript can be found here: Please, please read it when you have the chance! http://alistapart.com/article/writing-testable- javascript
11. MAINTAINABILITY A quick sidebar on maintainability, since maintainable code is less complex, simpler, and therefore more testable! When measuring your code's maintainability, there are certain well-established measures for evaluating how you've been doing and where you can improve. Cyclomatic Complexity Halstead Effort
12. CYCLOMATIC COMPLEXITY Measures the number of paths through your code, as generated from forked conditionals (switches, if/else, ||, etc).
13. HALSTEAD EFFORT The "grokability" of your code. How much time would it take someone to understand a method or a class.
14. TOOLS : An online tool for measuring your code. : Allows you to set rules * for complexity during your g r u n t build, or otherwise to quickly score your entire project. jscomplexity.org grunt-complexity
15. TESTING FRAMEWORKS The most prevalent BDD testing framework. Used by Angular, many others. Framework made for the jQuery project. Battle hardened there, TDD format. (Test Framework + Test Runner) A runner you provide an assertion library for. Chai is the most popular. Jasmine QUnit The Intern Mocha
16. TEST RUNNERS : A command-line tool for launching JavaScript unit tests in one or more browsers and reporting results. From the YUI team. : An effort to combine BrowserStack and Yeti for cross browser testing. Used by Angular to run their Jasmine tests. Yeti Bunyip Karma (formerly Testacular)
17. RELATED READINGS An interesting presentation (about a year old) from Addy Yosmani on large-scale JS app structure: The original article on BDD, by Dan North. Link Link http://blog.mattwynne.net/2012/11/20/tdd-vs-bdd/