Algorithms we develop software by

>> So you'd prefer your contracts to blow up your bugs in your clients' faces, rather than catch bugs yourself prior to releasing the code to them?!

> That's you arguing against contracts.

No. Notice what I wrote earlier? Where I very specifically said "contracts are awesome but not substitutes for unit tests"?

That's exactly the same thing I was saying here. I was arguing against relying on contracts to catch the bugs unit tests would've caught. Nobody was ever telling you to avoid contracts anywhere. Like I said, they're awesome, and both are valuable. I'm just saying they don't substitute for your unit tests. Just like how screwdrivers don't substitute for hammers, as awesome as both are.

> Saying contracts shouldn't run in shipped code misses the whole point about what contracts are.

I never said that, you're putting words in my mouth.

> No, unit tests test a portion of the software before shipping. My argument is they aren't worth the cost and provide little value. [...]

I just gave you a detailed, point-by-point explanation of what you've been missing in the other thread with your own purported counterexamples: https://news.ycombinator.com/item?id=41287473

Repeating your stance doesn't make it more correct.

Agreed. I've also heard this stated as:

> for each desired change, make the change easy (warning: this may be hard), then make the easy change"

(earliest source I could find is @KentBeck on X)

I love the idea of that vocabulary of tools and libraries, too. I strongly resist attempts to add to or complicate it unnecessarily.

I think the exercise is more about exposing you to other solution options (to 'break your anchoring bias'). You still have to exercise judgement as to which solution is right for the situation.

I'm not mempko, but I can answer that question---yes. For over a decade on the same code base with a team that ranged from 3 to 7 over the years. We did have what would be considered end-to-end tests, or maybe integration tests that tested the entire system from ingress (requests coming in) to egress (results going out) that ensured the existing "business logic" didn't break.

There were no unit tests, as a) the code wasn't written in a style to be "unit" tested, and b) what the @#$@Q#$ is a unit anyway? Individual functions in the code base (a mixture of C89, C99, C++98 and C++03) more or less enforced "design by contract" by using calls to assert() to assert various conditions in the code base. That caught bugs as it prevented the wrong use of the code when modifying it.

Things only got worse when new management (we were bought out) came in, and started enforcing tests to the point where I swear upper management believed that tests were more important than the product itself. Oh, the bug count shot up, deployments got worse, and we went from "favorite vendor" to "WTF is up with that vendor?" within a year.

I learned early on to automate the test system. It went from a 30-minute setup to run a 5-hour test (which I wrote) to one command that took maybe a minute to run all tests (which I also wrote, and by the end, you could specify just what tests you wanted to run). And yes, that one command generated all the test data and ran all the processes required to test.

Towards the end, management was asking to test for negatives ("Write tests to make sure that component T doesn't get a request when it isn't supposed to," when component T was a networked component that queried a DB not under our control). Oh, and our main business logic made concurrent requests to two different DBs and again, I had to write code to test all possible combinations of replies, timeouts and dropped traffic to ensure we did The Right Thing. Not an easy thing to unit test, as the picture you linked to elegantly showed (and, you side stepped my question I see).

The entire engineering team for the project was maybe 20, 25 people, but each team (five total) had full control over their particular realm, but all were required for the project as a whole. Our team did C and C++ on Solaris; three teams used Java (one for Android, and two on the server side) and the final team did the whole Javascript/HTML/CSS thang.

You're right that we didn't see much flux from the other teams, nor from our customer (singular---one of the Oligarchic Cell Phone Companies), but that's because the Oligarchic Cell Phone Company doesn't move fast, nor did any of the other teams want do deal with phone call flows (our code was connected to the Phone Network). We perhaps saw the least churn over the decade simply due to being part of the Phone Network---certainly the other teams had to deal with more churn than us (especially the Android and JS/HTML teams).

Also, each team (until new management took over) handled deveopment differently; some teams used Agile, some scrum, some none. Each team had control. Until we didn't. And then things fell apart.

If I was developing a library, the only tests I might have would be to test the public API and nothing more. No testing of private (or internal) code as that would possibly churn too much to be useful. Also, as bugs are discovered, I would probably keep the code that proves the error to prevent further regressions if the API doesn't change.

One thing I did learn at that job is never underestimate what crap will be sent your way. I thought that the Oligarchic Cell Phone Company would send good data; yes for SS7 (the old telephony protocol stack), but not at all for SIP (the new, shiny protocol for the Intarweb age).