For a very narrow range of software, I suppose. Not for software that has side-effects and actually does stuff in the real world.
What about software that sends emails to people, or places orders, performs billable work, or gives people directions, or supplies them with data that they then carry forward and use in decisions or in other systems?
And are you proposing that instead of writing tests you write a play-back-able-log system that can roll back state and re-apply transformations if a given component did incorrect things?
I think sensible testing is the way forward, where sensible is appropriate to the type of application, language and requirements. 100% coverage is suitable for industrial code and 1% coverage is appropriate for toy projects. But no tests at all seems foolhardy.
What about software that sends emails to people, or places orders, performs billable work, or gives people directions, or supplies them with data that they then carry forward and use in decisions or in other systems?
And are you proposing that instead of writing tests you write a play-back-able-log system that can roll back state and re-apply transformations if a given component did incorrect things?
I think sensible testing is the way forward, where sensible is appropriate to the type of application, language and requirements. 100% coverage is suitable for industrial code and 1% coverage is appropriate for toy projects. But no tests at all seems foolhardy.