Alternatives #1
Comments
oh, I don't do this kind of thing anymore. this was from my old mad-science project, that I've back burnered. |
@dominictarr what do you use to unit test some code and mock out dependencies that touch the database? |
databases are antipattern. |
mocking is an antipattern too. if you really think you need that... build injection into your module. module.exports = function (evilDbThing) {
return {
...
}
} and then go |
#winning |
@dominictarr that's a pain in the ass because the database is everywhere >_< And why inject variables into function. That's what |
well, if you want to use different things with the same interfaces... it's better to be explicit that some wacky hack. |
@dominictarr having looked at all the ways to be explicit. Using |
"database is everywhere" is probably the root of the problem. alternatively, you could just have a thing require('db')({mock...}) do that first, and it could set a global thing that returns the database the rest of the time... |
@dominictarr we have a bunch of I just want to swap everyones repo out for a mock one and not have to pass in the repo. It's about
vs
It's just a pain in the ass to pass everything in. Last time I did that I wrote a dependency injection framework called |
@dominictarr the global db backdoor to punch the I prefer |
@Raynos, you must make you own decision and live with it. |
@dominictarr remind me to not do the "ask your for advice then tell you, you are wrong and then argue with you about you being wrong" again. |
what do you use to do this kind of thing that is not this?
The text was updated successfully, but these errors were encountered: