[dataflow]

I feel there's something missing in what you describe, and I'm trying to pinpoint what it is...

I can see it working if you have very few developers touching each piece of code, or if you get to exert control over the final application. But I don't see how it can work for large codebases or teams over long periods of time (read: large businesses)... especially not for library development, where your team is only responsible for providing library functionality (like string.indexOf(string) in my example, or matrix multiplication, or regexes, or whatever libraries do) and you don't necessarily even know whom the users are. There is no "system" or "integration" at that point, you're just developing one layer of code there, which is the library -- a piece of code responsible for doing just one thing. How the heck do you make sure arbitrary team members touching code don't end up introducing silly bugs over time, if not with unit tests?

Have you built any commercial libraries in this manner, rather than applications? i.e. where everyone on your team is jointly responsible for your library's development (like the implementation of string.indexOf(string) in my example), and other folks (whether inside or outside the company) are the ones who piece together the libraries to create their final application(s)?

[mempko]

I updated my original post with examples. I also included this research paper from Microsoft that shows a clear advantage of contracts and code quality. https://www.microsoft.com/en-us/research/wp-content/uploads/...

Note also types are a contract. TypeScript is basically introducing contracts at a high level to javascript.

[dataflow]

> I updated my original post with examples.

Awesome, I'll dissect them and show you exactly where you're drawing the wrong conclusion ;)

> I wrote an article talking about design by contract and why it's better than TDD here

Nobody is advocating for TDD or disagreeing with that. Having unit tests != TDD.

> https://github.com/mempko/henhouse

So far as I can see, you're literally the only developer here -- which exactly illustrates my point. You can ignore a LOT of good engineering practices and be sloppy about a ton of things if you're the only developer (or one of a handful of developers), because hardly anything ever changes underneath you or without your knowledge. (Source: I've done it too.)

> See SQLite (uses assertions heavily)

SQLite has like... 3 developers? The vast majority, again, being 1 person. (I didn't even bother verifying your claim that they don't have unit tests, FWIW.)

> .NET framework from Microsoft

.NET absolutely has unit tests, here's one example: https://github.com/dotnet/runtime/blob/ebabdf94973a90b833925...

> Many of the C++ Boost libraries

All the ones I recall ever seeing have unit tests... which "many" don't? Here's one that does: https://github.com/boostorg/regex/blob/develop/test/regress/...

> Parts of Rust

Again, you're gonna have to cite what you're talking about because Rust definitely has unit tests: https://github.com/rust-lang/rust/blob/master/library/core/t...

> Parts of Qt. The Vala programming language, Ada GNAT... and many others.

I'm not gonna keep digging up their unit tests, you (hopefully) get the point above.

> I also included this research paper from Microsoft that shows a clear advantage of contracts and code quality

As I said above, nobody is arguing against contracts! A paper showing they're awesome doesn't mean they're substitutes for unit tests in every situation. Your paper only mentions the phrase "unit test" twice, and neither of them is saying DbC substitutes for them.