Welcome to Part 9 of this review of the Pluralsight course “Creating a JavaScript Development Environment” by Cory House.
Cory is a Microsoft MVP in C#, founder of OutlierDeveloper.com, avid tech reader, and speaker.
He believes in clean code, pragmatic development, and responsive native UIs.
He has also created reactjsconsulting.com, and has the authored Pluralsight courses including Building Applications with React and Flux and Building Applications with React and Redux in ES6.
Also in this series:
Part 1 – You Need a Starter Kit
Part 2 – Editors and Configuration
Part 3 – Package Management
Part 4 – Development Web Server
Part 5 – Automation
Part 6 – Transpiling
Part 7 – Bundling
Part 8 – Linting
Part 9 – Testing and Continuous Integration
Part 10 – HTTP Calls
Part 11 – Project Structure
Part 12 – Production Build
Part 13 – Production Deploy
Testing and Continuous Integration
Test Decisions Overview
Cory focuses on Unit testing in this module, but says Integration and UI testing is also worth looking into.
John Sonmez has a couple of courses on Selenium, and also see this from Jason Roberts:
When Unit testing we need to decide on the…
1. Framework
2. Assertion Library
3. Helper Libraries
4. Where to run tests
5. Where to place tests
6. When to run tests
Decision 1: Testing Framework
Cory introduces the following frameworks:
Mocha
Jasmine
Tape
QUnit
AVA
Jest
The key point is that you use a framework. Don’t think that there is a right/wrong answer on which one you choose because all of these options are good.
Decision 2: Assertion Libraries
We are given a quick overview of Chai, Should and Expect.
Cory uses Chai in this course due to its popularity.
Decision 3: Helper Libraries
Cory introduces JSDOM and Cheerio.
See his React and Redux course for more information on these.
Decision 4: Where To Run Tests
There are 3 categories of test runners:
Browser (e.g. Karma and Testem)
Headless Browser (e.g. PhantomJS)
In-memory DOM (e.g. JSDOM)
Decision 5: Where Do Test Files Belong?
This is a discussion of whether to put your test files in a separate project or to put them alongside the production JS files.
Cory recommends having your test files alongside your production files and explains why.
Decision 6: When Should Tests Run?
Cory recommends setting up your unit tests to run every time you hit save.
If you have integration tests, these should be run less often (on demand, or in QA) because they will be a lot slower than your unit tests.
Demo: Testing Setup
Cory summarises the plan of action and the tooling we will use.
We start by creating testSetup.js, require in babel-rgister and disable the webpack features that Mocha doesn’t understand.
In package.json we add a test script which runs mocha’s progress reporter.
For a list of available reporters for Mocha see https://mochajs.org/#reporters
Next we create our first unit test, importing in ‘chai’ and using the expect style.
We see that it passes with the expected value and fails with an unexpected value.
Demo: DOM Testing
We import JSDOM and Node’s file system library. The next unit tests check that it says hello.
This is a bit more complex than you might think. There’s an asynchronous call that occurs when we call jsdom, and we need to setup our test to be asynchronous.
We use Mocha’s done() function for the test to work correctly.
Demo: Watching Tests
We add a test:watch script and update our start script in our package.json, so that we run our tests on each save.
Why Continuous Integration?
Cory explains the many reasons why we should have a CI server reporting problems on checkin.
What Does Continuous Integration Do?
A CI Server can run the automated build. If it breaks it will say who broke it. It will also run your test suite and can check your code coverage.
Finally we can automate deployment of our app.
Choosing a CI Server
Cory introduces the following options:
Travis
Appveyor
Jenkins
Both Travis and Appveyor are free for open source projects and integrate well with GitHub.
Demo: Travis CI
We see that we can sign in to Travis using our GitHub account and are shown how to turn the GitHub repository on in Travis.
We need to add a .travis.yml configuration file to our project.
Cory pushes a change that makes a unit test fail, and shows us what it looks like when a Travis CI build fails.
Then we see this put back again and the CI build passes.
Travis works great for Linux environments but not for Windows.
Demo: Appveyor
Appveyor works for Windows and offers similar features to Travis.
It is configured using an appveyor.yml file. We see that the recommended configuration file is more complex than the Travis one, but Cory explains what is needed.
We see an appveyor CI build running and passing.
Zombie Code Kill 