Unfortunately I have no tests yet. My plan is to use testify an mockery to
generate tests for the Storage interface. I am aware of the fact that this
only tests the app code . For testing the database methods we'll start
integration tests against a real database.,
kind regards
Reinhard
Am
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
@all thx for your comments I think i understand now how to deal with the advise
of small interfaces.
--
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
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
hi,
firstnat 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
The advice regarding small interfaces goes further than just a simple
"don't put many methods in an interface" - it includes (and is based on) a
different philosophy of using interfaces. The advice assumes that you
shouldn create an interfaces for the database backend in the first place -
instead,
Dear all,
as far as I know it is recommended to keep actual interfaces as small as
possible and to form bigger interfaces via interface composiston.
Would be great if the community could advise me what the real benefits are.
Lets say i want to create an interface for the database backend like
