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?


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.

Reply via email to