Home/ Questions/Q 512573
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T07:20:01+00:00

I was thinking about well known article Hardware is Cheap, Programmers are Expensive by

  • 0

I was thinking about well known article “Hardware is Cheap, Programmers are Expensive” by Jeff Atwood and a recommendation of “Keep the Build Fast” by Martin Fowler.

My tried approaches:

  1. I’ve suffered from too slow tests which was caused by intensive use of database. I like that it is cheap.. at the beginning.
  2. I’ve tried a multitiered architecture with persistent-arrogant easy tested domain objects. I like that it is maintainable and easy to use. But it is expensive in terms of time.

In case when I have enough time resources I usually choose the second way, but most of the time I have to live with the first one.

How to find a more cost effective approach? Is it the first way with a quite powerful hardware?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I don’t like unit tests that hit anything external, be it a database or the filesystem. Many people would call these integration tests rather than unit tests.

    Execution speed is an issue with these kind of tests – but so is setup speed.

    You (or anyone else on your team) should be able to check out the code and tests from source control and run them immediately. They shouldn’t have to mess around creating databases. The harder the tests are to run, the less useful they are.

    Continuous integration is also much easier if your tests have minimal dependencies.

    I don’t think fast hardware can overcome the drawbacks of having external dependencies, because disk and network access is so much slower than in-memory access. An old machine running dependency-free unit tests will be quicker than a newer maching that has to hit disk and database.

    As for the tradeoffs between your two options, I think it’s a question of scale. If you have a single programmer on a small project, then I think that approach 1) would suffice.

    But the more tests you’re running, and the more people who need to run them, the bigger the drawbacks of not seperating out your unit and integration tests will be.

    It’s really a question of fixed costs verses variable costs. Setting up rigorous unit testing might take some time, but if your project is large enough you can ammortise the time spent over many months of increased productivity.

    As always, it depends on the specifics of the project. Good luck!

    • 0