Testing D database calls code for regression
Jonathan M Davis
newsgroup.d at jmdavisprog.com
Sun Mar 18 20:02:42 UTC 2018
On Sunday, March 18, 2018 19:51:18 aberba via Digitalmars-d-learn wrote:
> On Friday, 16 March 2018 at 21:15:33 UTC, H. S. Teoh wrote:
> > On Fri, Mar 16, 2018 at 08:17:49PM +0000, aberba via
> >
> > Digitalmars-d-learn wrote:
> >> [...]
> >
> > The usual way I do this is to decouple the code from the real
> > database backend by templatizing the database driver. Then in
> > my unittest I can instantiate the template with a mock database
> > driver that only implements the bare minimum to run the test.
> >
> > [...]
>
> Mocking a fake database can also be huge pain. Especially when
> something like transactions and prepared statements are involved.
>
> Imagine testing your mock for introduced by future extension.
The other way would be to create a test database (or databases) and use
those with the normal code, though you have less control over some stuff
that way. What makes the most sense depends on what you're doing and how
much you're able to really unit test the pieces as opposed to component
testing large chunks of the code at once. And the reality of the matter is
that sometimes testing is a pain, though in the long run, it pretty much
always saves time and pain even if it's a pain to get set up.
- Jonathan M Davis
More information about the Digitalmars-d-learn
mailing list