Writing to be testable is good but ideally tests shouldn’t drive the app
code. I’ll admit that I’ve written inconsistent database method patterns to
enable testing but then never wrote tests.
In that case there’s a global DB type (type DB struct { *sql.DB }) with a
global var of the type initialized at the start of main. The HTTP handlers
call DB methods on the global var, then ideally all of those DB methods use
the receiver instead of the global var. I’m not sure how I’d start now, but
the idea is those methods could be tested with a different DB (I’m not
familiar with any sql in-memory ones).
Can you describe your code and testing in more detail?
Thanks,
Matt
On Tuesday, March 13, 2018 at 12:39:40 PM UTC-5, Reinhard Luediger wrote:
>
> hi,
>
> first of all thanks for your reply. Indeed, the interface arose from the
> necessity of testing. Have you expierience with a memory sql driver? Could
> you recommend one?
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
