# Full Stack Integration Testing in Node.js
Mike Swift @swiftalphaone
Over time the cost of developer time gets more expensive if you don’t have tests. You can get away with it on a small code base – in fact small code base one or two devs testing probably adds cost.
So many kinds of tests – Unit, Regression, Integration, Acceptance, Visual
Integration tests – tests that go from start to finish using your actual product. You don’t isolate components.
## What makes good tests? Everything covered? A 2:1 code to test ratio?
1. Don’t make assumptions
2. Test sufficient (and the right inputs)
3. Maintain clear goals
4. Isolate the things you are testing
5. Optimize for developer happiness
Test boundaries and an element in the middle.
Don’t forget about the zero case – what if there are no users/orders/etc.
If you can’t tell what you are testing with a test, it is not a good test.
Improper isolation can cause random failures, which reduces the effectiveness of your test suite (and the confidence of your developers)
If you are writing tests for the sake of writing tests, you are probably doing it wrong.
“Writing bad tests is way worse than not writing tests.”
## Writing Better Tests
What does “Full Stack” mean?
Load the app in a browser and test as a user would use it
Phase 1 – Load the page in a browser*
Phase 2 – Perform the necessary actions (and verfiy)
Phase 3 – Profit
*Simulated browers are acceptable
Complexity + More & more tests = Wasted Dev Time
Time waiting for build to run
So integration tests can be expensive
There are “cloud based” testing services – Selenium Grid, browserlin, saucelabs
Basically headless browers running in the cloud that can run various brower versions
Only work for client-side code – can’t test server side code
PhantomJS v. Selenium v. jsDOM
jsDOM is not a browser at all – it is just an implementation of a DOM – give it HTML and it creates a DOM that you can use.
Zombie.js works as headless brower and is written on top of jsDOM. It gives you a cleaner API based on jQuery selectors.
Vows, Jasmine, and Cucumber are potential testing libaries to use.
The nice part of testing with a brower is the brower resets the state of your system with every page load. Even a headless browser.
Step definitions become reusable for other tests of the feature.
## The Tool Belt
It allows you to assert that the expected calls were made.
Forgery (not sure why you would use this – I missed the explanation – it’s been a long week)
Travis is a very simple CI server that can integrate with github.
## Demo time
Testing a Sinatra app
You should start from an empty data store state (so you’d want to use an empty database or clear out your data in the test init (which is better for a demo 🙂 ))
You create a world object as your starting point for your test suite (basically a context). You should start your app/site there.
Testing a C# app