5 ms·

I've always found unit testing to be the best way to test drive small units of code, and integration tests the best way to find and prevent regressions in the i

• twic 11y ago
  Have you tried writing the integration spec first? My workflow is to start with the coarsest-granularity, most outside-in test i can. The nice thing about those tests is that you can write them based on the requirements, without thinking about implementation much, and then directly see what implications they have for implementation. Whereas if you start with fine-grained tests, you only discover the constraints that the requirement imposes on the implementation when you bump up against them halfway through development.
  • eric_h 11y ago
    I was intentionally brief in describing my workflow, obviously different features require different flows. If the integration test can be covered by simple requests specs for the api, then I will write that first. If, however, the feature requires a bunch of pointy-clicky feature tests, then I will write the integration tests afterwards (I do a lot of single page web apps, so pointy-clicky specs can be important, but are too slow to test drive with). [Edit: of course this is still a gross generalization, none if this is a hard and fast rule]