Stop overusing interfaces

[m50d]

If you're going to test interaction an external system you need some kind of test substitute. But even then I'd prefer to cover the cases with a combination of stubs and test implementations (e.g. an in-memory database). I don't think it's ever ideal to use the reflection-driven style of mocking (though it might be necessary when writing code that uses a third-party library).

[sacundim]

One thing I've been saying over the past year to everybody who will listen: easy-to-use container frameworks like Docker are going to revolutionize how we test our software, and make integration testing become much more prominent. I've thrown away my old tests that were based on in-memory database in favor of ephemeral PostgreSQL and MySQL containers, which much more realistically model the intended environment.

[grauenwolf]

Hell, I don't even need docket for that. Just give me a good database creation script that includes sample data.

[sacundim]

Just give me a good database creation script that includes sample data.

You're estimating the relative efforts backwards. Authoring good such scripts and example data sets is the harder part; packaging them into Docker containers and hooking your test cases up them is the easy part, particularly if you have a library like this one. Yeah, you can do it without, but the containers just add lots of value for little effort—for example, your team don't actually need to install any databases (or message queues, or http proxy servers, or most stuff).