3 ms·

Re: automated testing. This can be quite time consuming to set up in many environments. Step one: get an Oracle database instance/schema that you can snapshot

Re: automated testing. This can be quite time consuming to set up in many environments. Step one: get an Oracle database instance/schema that you can snapshot and roll back to a known starting state at will. Step two: get multiple connected app instances into a state to support each test run. Step three: just drop it, those things aren't gonna happen before you update your resume :-) I'm ignoring the approach that says: Let's just spend a LOT of time writing mocks that stub out 90% of everything that matters, and pretend that the tests actually show something that matters.

mi100hael 10y ago
No offense, but I think you're testing things all wrong. With any halfway-decent mocking library (which every major language I've encountered has), it's trivial to mock a HTTP client or ORM class or whatever and say "when called with foo, return bar." It should take no more code than it would to do the live data setup/rollback, and can be run in a completely isolated manner. If you only mock the calls that hit an external service, your tests will be more accurate because you've removed the chance of erroneous failures due to a problem with the external service. Spend the few hours it takes to learn to do it the right way once, and you'll never have to deal with all that nasty live setup/coordination/teardown again.
the_af 10y ago
Agreed about integration tests sometimes being a pain in the... neck. However, note I'm talking about something way more basic: many business don't do any kind of testing at all that isn't done by people manually trying the system. In the case of internal tools, this "testing" is often done directly by internal users trying to use the tool. This is way more common than one would suspect from reading tech blogs (unless one reads TheDailyWTF, of course).
- mgkimsal 10y ago
  I try to stress to clients that testing will always be done - we have a choice how much we do up front, behind the scenes, vs out in public, with real customers, money and data on the line. Still people choose, for a number of reasons, to have some/most/all of testing just be 'throw it out and see what happens'.

mi100hael 10y ago

No offense, but I think you're testing things all wrong. With any halfway-decent mocking library (which every major language I've encountered has), it's trivial to mock a HTTP client or ORM class or whatever and say "when called with foo, return bar." It should take no more code than it would to do the live data setup/rollback, and can be run in a completely isolated manner. If you only mock the calls that hit an external service, your tests will be more accurate because you've removed the chance of erroneous failures due to a problem with the external service. Spend the few hours it takes to learn to do it the right way once, and you'll never have to deal with all that nasty live setup/coordination/teardown again.

the_af 10y ago

Agreed about integration tests sometimes being a pain in the... neck. However, note I'm talking about something way more basic: many business don't do any kind of testing at all that isn't done by people manually trying the system. In the case of internal tools, this "testing" is often done directly by internal users trying to use the tool. This is way more common than one would suspect from reading tech blogs (unless one reads TheDailyWTF, of course).

mgkimsal 10y ago
I try to stress to clients that testing will always be done - we have a choice how much we do up front, behind the scenes, vs out in public, with real customers, money and data on the line. Still people choose, for a number of reasons, to have some/most/all of testing just be 'throw it out and see what happens'.