3 ms·

This is a good article. The title says conquer technical debt, but much of the article is about becoming comfortable with the technical debt. In fact, all cod

by nissimk 11y ago

This is a good article. The title says conquer technical debt, but much of the article is about becoming comfortable with the technical debt. In fact, all code is debt. As systems become larger, they are harder to modify and maintain. All of the supposed engineering techniques that prevent this are pseudo science snake oil. I'm sure many engineers would consider the "shims" described in this article to be further technical debt, but they increase agility and are frequently worth the cost. I particularly liked the description of automated tests as jigs. Rather than unit testing small components of code, I've always believed that integrated tests that cover as much of the functional surface as possible are better. Tests for regressions of any bugs that were fixed and a performance / integration test suite can go a long way towards increasing comfort in making changes to complicated systems.

eric_h 11y ago
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 integration of those units. My workflow over the last few years has been test drive a unit, plug it into the application, write an integration spec.
- 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]

by nissimk 11y ago

eric_h 11y ago

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 integration of those units. My workflow over the last few years has been test drive a unit, plug it into the application, write an integration spec.

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]