4 ms·

By my personal experience to make TDD work (where you make many small changes, run the tests, make more changes - step by step), tests need to run FAST - as in

by hooby 5y ago

By my personal experience to make TDD work (where you make many small changes, run the tests, make more changes - step by step), tests need to run FAST - as in ideally less than 1 second. Even if it is easy to spin up a container, seed a database inside that container and drop and recreate that database after every single test (so that tests remain a unit and can't influence each other) - it tends to take a few seconds, which instantly makes TDD tedious to do. Thus you start making more changes at once, run the tests less, and drift away from doing TDD... The most typical solution is to run databases in-memory rather than in a container. My personal approach though is to make my code more modular, so that only the "database accessor" class needs to mock the actual database, while the "query builder" needs to mock only that database accessor (much easier) - and the database class needs to only mock the query builder (even easier) - and the actual application code needs to only mock the database class (super easy).

WolfOliver 5y ago
It is not hard to isolate and stub a database the problem is you will not catch a lot of errors, e.g. writing a 40 char string into a VCHAR(10), DateTime conversations, ... In Ruby on Rails it is quite common to use a real database in the unit tests. Even before containers came out and it is still fast (yes, less than 1 second). In rails you use the same database instance for all the tests, so you do not have spin up a database instance for every case. Instead you use a database cleaner. There also exists a JS implementation: https://github.com/khaiql/dbcleaner https://github.com/khaiql/dbcleaner
krageon 5y ago
> Even if it is easy to spin up a container, seed a database inside that container and drop and recreate that database after every single test You would create a container image with everything already prepared how it should be, and you destroy it after every run - that's already a lot faster than what you're proposing.

by hooby 5y ago

WolfOliver 5y ago

It is not hard to isolate and stub a database the problem is you will not catch a lot of errors, e.g. writing a 40 char string into a VCHAR(10), DateTime conversations, ... In Ruby on Rails it is quite common to use a real database in the unit tests. Even before containers came out and it is still fast (yes, less than 1 second). In rails you use the same database instance for all the tests, so you do not have spin up a database instance for every case. Instead you use a database cleaner. There also exists a JS implementation: https://github.com/khaiql/dbcleaner https://github.com/khaiql/dbcleaner

krageon 5y ago

> Even if it is easy to spin up a container, seed a database inside that container and drop and recreate that database after every single test You would create a container image with everything already prepared how it should be, and you destroy it after every run - that's already a lot faster than what you're proposing.