4 ms·

> I want to actually load the data and see it happen. Because if I don't, how do I know that my code will actually work in production? This would fall under th

> I want to actually load the data and see it happen. Because if I don't, how do I know that my code will actually work in production? This would fall under the purview of integration/acceptance testing?

brianwawok 10y ago
I don't really want to split hairs about what test is what test. I do not write a test that would involve mocking a database. If I have 1 test, it is going to be 1 test that uses the database. Its "the test".. not a "unit test" or an "acceptance test" or a "integration test".. just, "the test."
- softawre 10y ago
  My goal is to be pragmatic with testing. We have "tests" that actually spin up a real database too, but not all of our tests do that. Where I'm with you is fighting the "architects". The guys that will constantly say you're not doing "real unit testing" and that you should mock every function (and then have to change every mock with every change and blah blah). To me, being pragmatic with testing is a key component of GTD in modern software development.
- ng12 10y ago
  Are you working with other developers on these projects? "The test" failing is much less useful information than a "unit test" failing. If the unit test fails I know it's something pretty fundamental -- I can isolate it to a single method. If the integration test fails, but the unit test passed, I can be reasonably assured the problem is with the database. Tests are just as much about making software maintainable as they are about making sure it's correct.
  - brianwawok 10y ago
    Yes, these were for fortune 2000 companies or late state startups... projects with piles of "unit tests" where you try to test one class at a time and hand type what a database does were all inevitably crap, and either failed and got rewritten, or all the crap got written out.
- wlamartin 10y ago
  That's fair if you don't want to make that distinction but it is common vernacular and each testing layer has a set of properties which lead to separate pros and cons. The discussion then becomes, "what are the advantages/disadvantages of testing in isolation versus testing integrated components" which is a well trodden topic. In a previous comment you mentioned that you get huge efficiency gains testing everything together. Well, during writing you could make that argument (though I would consider that contentious) but when it comes to maintenance and refactoring, I would argue having "the test" is going to result in a much larger surface area for you to debug when you change something and "the test" breaks.

brianwawok 10y ago

I don't really want to split hairs about what test is what test. I do not write a test that would involve mocking a database. If I have 1 test, it is going to be 1 test that uses the database. Its "the test".. not a "unit test" or an "acceptance test" or a "integration test".. just, "the test."

softawre 10y ago
My goal is to be pragmatic with testing. We have "tests" that actually spin up a real database too, but not all of our tests do that. Where I'm with you is fighting the "architects". The guys that will constantly say you're not doing "real unit testing" and that you should mock every function (and then have to change every mock with every change and blah blah). To me, being pragmatic with testing is a key component of GTD in modern software development.
ng12 10y ago
Are you working with other developers on these projects? "The test" failing is much less useful information than a "unit test" failing. If the unit test fails I know it's something pretty fundamental -- I can isolate it to a single method. If the integration test fails, but the unit test passed, I can be reasonably assured the problem is with the database. Tests are just as much about making software maintainable as they are about making sure it's correct.
- brianwawok 10y ago
  Yes, these were for fortune 2000 companies or late state startups... projects with piles of "unit tests" where you try to test one class at a time and hand type what a database does were all inevitably crap, and either failed and got rewritten, or all the crap got written out.
wlamartin 10y ago
That's fair if you don't want to make that distinction but it is common vernacular and each testing layer has a set of properties which lead to separate pros and cons. The discussion then becomes, "what are the advantages/disadvantages of testing in isolation versus testing integrated components" which is a well trodden topic. In a previous comment you mentioned that you get huge efficiency gains testing everything together. Well, during writing you could make that argument (though I would consider that contentious) but when it comes to maintenance and refactoring, I would argue having "the test" is going to result in a much larger surface area for you to debug when you change something and "the test" breaks.