Types of Tests | Hacker News Reader

Types of Tests

searls.test-double.com

36 pointsdavemo6 comments

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 :)

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.

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?

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).

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

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

Reply on news.ycombinator.com