| If you have to write mocks in the native language, mocks will probably drive you insane. Tools like mockito can make a big difference. I worked on a project which was terribly conceived, specified, and implemented. My boss said that they shouldn't even have started it and shouldn't have hired the guy who wrote it! Because it had tests, however, it was salvageable, and I was able to get it into production. This book https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe... makes the case that unit tests should always run quickly, not depend on external dependencies, etc. I do think a fast test suite is important, but there are some kinds of slower tests that can have a transformative impact on development: * I wrote a "super hammer" test that smokes out a concurrent system for race conditions. It took a minute to run, but after that, I always knew that a critical part of the system did not have races (or if they did, they were hard to find) * I wrote a test suite for a lightweight ORM system in PHP that would do real database queries. When the app was broken by an upgrade to MySQL, I had it working again in 20 minutes. When I wanted to use the same framework with MS SQL Server, it took about as long to port it. * For deployment it helps to have an automated "smoke test" that will make sure that the most common failure modes didn't happen. That said, TDD is most successful when you are in control of the system. In writing GUI code often the main uncertainty I've seen is mistrust of the underlying platform (today that could be, "Does it work in Safari?") When it comes to servers and stuff, there is the issue of "can you make a test reproducible". For instance you might be able to make a "database" or "schema" inside a database with a random name and do all your stuff there. Or maybe you can spin one up in the cloud, or use Docker or something like that. It doesn't matter exactly how you do it, but you don't want to be the guy who nukes the production database (or a another developer's or testers database) because the build process has integration tests that use the same connection info as them. https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe... |