Unit testing tells you what you already know. It's kind of pointless, when you think about it (unpopular opinion). If you have a handle on your code there's rarely any need for it.
[1] I used to have an error logging mechanism in place that would record where in the code the error happened (in addition to other information) and how it propagated up through the code.
While it wasn't that hard to use, per se, it was bothersome when I had to add an error (each error had a unique ID and because of language issues and tooling, that was a manual process). And it really never paid back its implementation cost in terms of reporting, so I finally ripped it out.
[2] I had my own version of C's FILE* [3] that ended up being a horrible abstraction---it was so confusing that I could never remember how to use it, and I wrote the code. I got fed up with it, and ripped that out, replacing it with native IO calls.
[3] For stupid reasons now that I think back on it.
Do you like going back to manually verify things still worked after you make a foundational change? Or do you just trust yourself to know you've not impacted anything negatively? Do you honestly believe that's good use of your brain power even if true? Do you enjoy being married to that code? Because that's exactly what happens as nobody but you can work on it. That strategy works out well for employees to become key men and get big retention bonuses so there is some merit to your approach :-)
Not to mention the team impact to cowboy coding. It's a selfish approach to software development and is often undertaken by bully developers that say things like "use the source" as a way to make you feel dumb for not wanting to spend all day trying to untangle their likely insane code. All because they were too lazy to use a little empathy and be a good teammate.
To recap: Tests document and improve your design, verify functionality, provide leverage to accelerate development, and reduce "bus factor" risk. I don't care what a small sample data set says to the contrary there's really little debate that when wielded properly these tools and techniques do improve software on multiple dimensions that go beyond the software itself and heavily impact the business.
20+ years of product development experience in lots of teams/products inform this opinion. Let's see the data on how your business grinds to a halt when these tools aren't used and the code base gets increasingly larger and complex and people leave. Tell me about how you don't need those automated tests as you approach technical debt bankruptcy and all your key people have left. "Use the source" is a terrible response to that problem.
Rewrites can be fun though so maybe that's the answer. It sure worked out well for Netscape. ;-)
1) They run whenever the product runs. Good logging code tells you when it fails, even on customers devices.
2) By being part of the production code, they are far easier to keep up to date as the code changes even through refactoring.
3) They don’t force you to change anything about how you code.
BTW, the code is an ecommerce platform, not just a website but dozens of integrated applications that handle everything from product selection to order fulfillment, and everything inbetween. 11 years of code that dozens of people use daily to process hundreds of thousands of orders per year.
1) It takes more time.
2) In any complex application, unit testing requires creating mocks to separate the code you are testing from live subsystems.
3) That requires modifying your production code to be easily mockable in ways that don’t benefit the production code base.
4) Unit tests are by default artificial. They don’t test real world usage.
5) As you refactor production code, you have to rewrite unit tests, adding more overhead.
A far better way to write tests is within your production code. Validate every parameter and every assumption. Raise errors when possible, log everything else.
This is far easier to develop, and maintain. It runs when you testers, and customers use the applications.
Now I write desktop and mobile apps. If I wrote APIs and servers unit tests would become far more useful. But on device most of my problems can only be caught by integration tests, not unit tests.
> It runs when you testers, and customers use the applications.
Do you rely on any sort of automated testing to catch errors before it gets to your customers? From a business standpoint it doesn't feel right to offload testing to your users, especially in more critical systems.
Verification isn’t offloading testing, it’s monotoring real world usage to find out where it differs from testing. The hard part is the logs can be a torrent of data, you need to have a process to monitor and escalate.
i’d like to automate testing. But it has to be no more work than manual testing, and/or it has to be as effective or better than manual testing. And i can’t see either of those being true.
Most of my bugs can’t be caught by unit tests. For example one common category is where previous devs made assumptions where code normally works fine, but fails in specific edge cases from multiple thread timing or view controllers being disposed. i don’t know how to automate those tests.
As you scale codebases and teams, it becomes necessary. With small single-developer projects, it's not.