3 ms·
I work on a service where a big percentage of the code is persisting to and reading from various stores, so unit tests have very limited value compared to integ
by jimbokun 2y ago
I work on a service where a big percentage of the code is persisting to and reading from various stores, so unit tests have very limited value compared to integration tests.
- jrockway 2y agoYeah, if you can start up the actual things, then you know your code's going to work against the actual things. That's ultimately what we're aiming for.
- mrkeen 2y agoThat's not sufficient. The actual things are IO devices, and will sometimes fail and sometimes succeed. No judgement, just a fact of life. I code my tests such that my logic encounters successes, timeouts, exceptions, thread-cancellations, etc. All at unit-test speed. I can't trick an MSSQL deployment into returning me those results. It doesn't take 30 seconds to test what your system will do in 30 seconds.
- mrkeen 2y agoIs this not a solved problem? Why do you need to write so much persistence logic?
- jimbokun 2y agoI have no idea how to interpret your comment. Do you mean just throw an ORM library into your code and never give another thought to persistence issues? At scale, there will always be challenges with latency, through put, correctness, and cost of persisting and retrieving data that require considering the specifics of your persistence code. The service I’m describing handles abstracting these persistence concerns so other services can be more stateless and not deal with those issues.