4 ms·

It's not just DB. What about 3rd-party Web Services (Facebook, Amazon, etc). Also, can you run the whole thing in your continuous integration build? Setting up

It's not just DB. What about 3rd-party Web Services (Facebook, Amazon, etc). Also, can you run the whole thing in your continuous integration build? Setting up Database to run on a CI server sometime is problematic (depending on how you setup your CI, if you're using Amazon EC2 instances...). Rails solved this problem to some extend by using SQLite but one needs to install + configure SQLite for various machines. Speed is another thing. The more you write tests that hits the DB, your automation-test will take a performance hit and you'll have to do something eventually. What if you have caching by utilizing some sort of caching server? that needs to be installed and configured as well. What if the only way to test the code is to deploy it to the server and write raw HTTP GET/POST because those are the only entry point? In 2011, where there are better tools and known practice, I don't think we should labelled some of these practices as YAGNI and Premature Optimization. First of all, it's not YAGNI if you have to refactor or write another framework, tools, or some sort of patches in order to have an acceptable build time. Second, it's not Premature Optimization if the tools, the libraries, and the environment provide you with ways to implement them in no time. I think the excuse of Premature Optimization is used a lot in a context where it doesn't mean what it supposed to mean.

deleted 15y ago
[deleted]
ubernostrum 15y ago
I think the excuse of Premature Optimization is used a lot in a context where it doesn't mean what it supposed to mean. Which may be why I didn't use the phrase. In all seriousness, though, I can sit down and come up with dozens -- heck, hundreds -- of "well, what if" cases. And you know what? I don't care about 'em. I went through the phase of abstractly decoupling everything to the Nth degree because of "what if" cases. And I paid for it; I was overlooking simple and often more elegant solutions to actual problems in favor of complex solutions to hypothetical problems. Does using a real database instead of decoupled MockableWriteableDataStorageInterface mean my tests take a few extra seconds to run? Yup. Does the time I'd save running tests by writing and passing in a MockableWriteableDataStorageInterfaceImplementation outweigh the increased complexity and thus mental load of the codebase? Unlikely. And, importantly: does testing with something that isn't a real database potentially cover up bugs that only happen when I use a real database? Yup, and that happens often enough that the whole mockable thing just goes out the window right there. Anyway. I think most developers go through this phase, too, and I think it's similar to the way people spend disproportionate amounts of time worrying about dramatic but unlikely things (shark attacks, terrorists, etc.) rather than dealing with the mundane but extremely likely things right in front of them.
- hello_moto 15y ago
  Those "what ifs" had hit me in a few projects already. This is why spring-test module from Spring Framework is very helpful if you're doing Java projects. I don't have to deploy "war" to Tomcat or Jetty. I can mock the Request and Response object. We do have integration-tests that test specifically component that interact with databases. But there are another set of unit-tests that test the business/process workflow and assume the database will return something relevant. We do this because we want to write many tests with focus specifically to business/process workflow related code, not the database layer. This way we can write more tests without paying the taxes of: performance and setup (when you have a huge database models, it's not fun to prepare the models for each-single-unit-test that has to touch the database even though the purpose of that unit-test is not to test the database). So far this model has worked well for us (i.e.: no more excuses that build takes too long or writing unit-tests take too long due to the setup both infrastructure and preparing huge model).

deleted 15y ago

[deleted]

ubernostrum 15y ago

I think the excuse of Premature Optimization is used a lot in a context where it doesn't mean what it supposed to mean. Which may be why I didn't use the phrase. In all seriousness, though, I can sit down and come up with dozens -- heck, hundreds -- of "well, what if" cases. And you know what? I don't care about 'em. I went through the phase of abstractly decoupling everything to the Nth degree because of "what if" cases. And I paid for it; I was overlooking simple and often more elegant solutions to actual problems in favor of complex solutions to hypothetical problems. Does using a real database instead of decoupled MockableWriteableDataStorageInterface mean my tests take a few extra seconds to run? Yup. Does the time I'd save running tests by writing and passing in a MockableWriteableDataStorageInterfaceImplementation outweigh the increased complexity and thus mental load of the codebase? Unlikely. And, importantly: does testing with something that isn't a real database potentially cover up bugs that only happen when I use a real database? Yup, and that happens often enough that the whole mockable thing just goes out the window right there. Anyway. I think most developers go through this phase, too, and I think it's similar to the way people spend disproportionate amounts of time worrying about dramatic but unlikely things (shark attacks, terrorists, etc.) rather than dealing with the mundane but extremely likely things right in front of them.

hello_moto 15y ago
Those "what ifs" had hit me in a few projects already. This is why spring-test module from Spring Framework is very helpful if you're doing Java projects. I don't have to deploy "war" to Tomcat or Jetty. I can mock the Request and Response object. We do have integration-tests that test specifically component that interact with databases. But there are another set of unit-tests that test the business/process workflow and assume the database will return something relevant. We do this because we want to write many tests with focus specifically to business/process workflow related code, not the database layer. This way we can write more tests without paying the taxes of: performance and setup (when you have a huge database models, it's not fun to prepare the models for each-single-unit-test that has to touch the database even though the purpose of that unit-test is not to test the database). So far this model has worked well for us (i.e.: no more excuses that build takes too long or writing unit-tests take too long due to the setup both infrastructure and preparing huge model).