So hypothetically, in your opinion, can build time be used as a proxy for coupling?

Well, I don’t know for sure. It doesn’t look like it at first glance, but if that was my system for real, I’m sure I’d have a few integration tests that covered some common scenarios, because the consequence of failure is so high. But I wouldn’t run those tests on every check-in of the code.

I have a service that routes cars through traffic lights. I test that cars only go through lights when they are green.

I have a service that co-ordinates different traffic lights & test that intersecting lights are never green at the same time.

I can logically conclude that cars won’t crash in intersections … but I don’t test it, because that would be an integration test. Have I missed something important?

To share another success story: I’ve been working on my current project for a year. This project is far more complex than any rails app I’ve ever worked on. I took what I had learned from Destroy All Software, Objects on Rails and GOOS and applied it to how we structured our code and how we tested it, and here’s where we’re at:

$ time bin/rspec spec/unit

Finished in 2.72 seconds (including 1 forced GC cycle(s), totalling 0.42926 seconds)
709 examples, 0 failures, 9 pending

Randomized with seed 2969

bin/rspec spec/unit –format progress 4.99s user 1.02s system 94% cpu 6.356 total

Running all of unit tests takes 6.35 seconds, and more than half of that is spent loading all the code.

The clearly defined interfaces between the components of our system have enabled us to make some large scale changes, all while getting virtually instantaneous feedback from our unit tests.

Jem, the idea is that if you have clearly defined contracts between your services, you only need to test a small number of interactions. Then thoroughly test the behaviour of the individual services. Testing everything from the outside leads to combinatorial explosion, and ultimately, madness.

Thanks

I encourage programmers to “reinvest” this their test speed profits to improve the design and reduce the number of dependencies. This increases cohesiveness and decreases code dependency on its context.

So it is for the build: reinvest the build speedup profits to split the system into smaller, more cohesive modules, each of which builds in seconds or minutes. Thanks for sharing.