|
|
|
|
|
|
by mrkeen
632 days ago
|
|
|
It is for testing, but you don't indirect over class A because you want to test class A, you do so to test class B. By all means, write a test to make sure the queries actually work on the database. It will be slow, stateful and annoying, but still probably worth it. But you don't want to bring that slow-statefulness over to every other upstream test in the entire system: want to test if the permission system (in some outer class) is allowing/blocking correctly? You'll need to start up a database to do so. Is your test making sure that an admin with permissions can create a user (without error?), well it's going to start failing due to USER_ALREADY_EXISTS if you run the test twice. To avoid that you'll need to reset and configure its state for every single invocation. |
|
|
Good testing frameworks just do this for you.
I generally prefer focusing testing efforts around what you describe - spinning up the entire system under test - because that's how the system is used in real life. There's definitely times you want to test code in isolation statelessly, but I find that engineers often err on the side of that too much, and end up writing a bunch of isolated tests that can't actually tell you if an http call to their API endpoint performs the correct behavior, which is really what we want to know.