Thinking about - week 31
Writing tests that use an actual database is hard.
- that results from tests against your test system have (almost) no meaning
- that your tests will not cover some of the most complex aspects of your productive system
- that you will start spending way too much time on tweaking tests rather than implementing useful business logic
Databases couldn’t be any less stateless. The whole idea of a database is to manage state. And that’s very complicated and completely opposite to what any unit test can ever model
My database unit testing is about testing SQL syntax only.
- Database increment
- Database migration
- Code re-generation
Good combination of tools. I would like to use. But those Oracle DBA guys do not like using tools which are not used to (even if it is more advanced)
I’ve long believed that the design of your software has a profound impact on how users behave within your software. But there are two sides to this story:
- Encouraging the “right” things by making those things intentionally easy to do.
- Discouraging the “wrong” things by making those things intentionally difficult, complex, and awkward to do.
The purpose of locks, the locksmith said, is to protect you from the 98% of mostly honest people who might be tempted to try your door if it had no lock.
10% of people will never steal, 10% of people will always steal, and for everyone else … it depends.
most people will consistently and reliably cheat “just a little”, to the extent that they can still consider themselves honest people.
Once upon a time I have made a test whether I am a good man. For example a good man does not steal. And first question: Have you ever taken a pen from your workplace for private use? Of course I did….
a simple reminder at the time of the temptation is usually all it takes for people to suddenly “remember” their honesty.
You do it by showing them …
- the minimum helpful reminder
- at exactly the right time