

Types of Tests - davemo
http://searls.test-double.com/2012/04/01/types-of-tests

======
davemo
I learned a lot reading this; in particular the discussion about fragility as
it relates to using test-doubles for some collaborators and not for others in
a single test instance. However, I absolutely love your conclusion hook as it
validates (most of) my testing worldview.

I only say "most of" because I have rarely worked on a team where maximally
realistic tests were anything but slow/fragile monstrosities that became stale
very quickly.

I <3 isolation testing :)

~~~
searls
I'd be uncomfortable relying _only_ on isolation tests, as they won't add much
confidence that the application is in a working state.

For any project that's important, I'd really encourage even just one or two
full-stack smoke tests that take a stroll through the system (as a separate
build on CI). Most full-stack tests only become unbearably slow when they
attempt to exhaustively cover everything in the application.

~~~
davemo
As an example, the current "application" I'm working on is basically a client-
side implementation of an Excel spreadsheet written using Backbone.js. The
idea of "maximally realistic tests" in this project involve manually comparing
the calculations I've implemented in JavaScript to see if they match the
output in the Excel sheet.

So, we've got great isolation tests that cover the UI functionality in the
webapp and some simple calculation tests that verify behaviour for equations
by providing the same inputs as the spreadsheet and verifying the output is
the same (in this case, that means copy/pasting excel table values into the
.toBe(expected) part of my specs).

I'm wondering, in this case how would I write remote full-stack or local full-
stack tests?

~~~
searls
All things being equal, I'd start with just one full-stack test that used a
typical existing instance of a spreadsheet as reference for its test data,
then I'd automate a browser to fill in all the inputs into your new single-
page app, and I'd finally assert that the computations match the results on
the reference spreadsheet. That way, the full-stack test treats the new
application as a black box and validates that the new implementation is still
working like the old one (at least in the cases of whatever reference
spreadsheets you throw at it).

------
searls
I'll be checking this thread today and would be happy to respond to anyone's
feedback or criticism.

------
codereview
There's a lot of misconception about tests. If you're interested in how to
start unit testing, check out this tutorial on Wednesday: <http://j.mp/HPguPs>

