Sorry, are you saying unit testing is dumb? Not that you'd be the first to say such a thing, but I've never really understood this if people find them valuable. 100% test coverage is one thing, but having some interdependent functions that do one small thing is a perfect use case for unit tests.
The last comprehensive study I read indicates that they improve internal and external code quality by 76% and 88% respectively while reducing productivity some[1]. If you have papers that indicate your claim I'd be interested in reading them or in ones that refute the metastudy linked below.
Confused, how do you ensure that a change to your implementation of some function isn't going to break clients after deployment if you don't have a unit test?
You would obviously test the software before it goes to the users. With contracts you would be able to have information from your users that make it MUCH easier to fix. Without contracts you will have a much harder time fixing the bugs. Contracts catch bugs unit tests don't.
No, a unit test is a stand alone bit of code that sets up the environment, runs a bit of code (the unit under test) and checks if the code worker as expected. This does tend to use assertions.
The idea of using assertions, is to put the assertions inside the 'unit under test' so they are checked every time the code is run (sometimes with a way to disable for performance). Then you can run the code normally, and don't need to write a separate bit of code, that has to set up a proper environment (usually with a lot of 'mock' objects).
This style can probably test less, but still works well for 'design by contract'. You can confirm the caller stuck to any requirements of the input, and you can confirm the code stuck to any post-conditions on it's results.
But assertions only tell you you broke someone after the fact (and only if they're enabled)? They don't do anything to help prevent you from breaking them in the first place.
> A spike is a product development method originating from extreme programming that uses the simplest possible program to explore potential solutions.
In my career, I have often spiked a solution, thrown it away, and then written a test to drive out a worthy implementation.
0. https://en.wikipedia.org/wiki/Spike_(software_development)