Testing D database calls code for regression

[H. S. Teoh]

On Mon, Mar 19, 2018 at 06:45:49PM +0000, aberba via Digitalmars-d-learn wrote:
[...]
> The thing about functional programming where functions are
> decoupled/testable doesn't seem to apply to database call code. I
> guess its because databases introduces a different state...another
> point of failure.

Not necessarily; in some cases it may be possible to design code such
that its logic can be tested independently of an actual database.  But
that may not be practical in your case since it will likely involve a
major rewrite.

Basically, it's pretty rare for an application to actually need the full
range of the SQL language + *all* of the features your database backend
provides.  Usually, the "business logic", so to speak, boils down to
just some simple primitives: uploadFile(), createAccount(), loginUser(),
logoutUser(), deleteAccount(), retrieveFile(), etc..  Ideally, the
business logic part of the code should not even care about whether
there's a database in the back supporting these operations; it should be
higher-level code built on top of these high-level primitives.  There
should definitely not be any literal SQL statements anywhere at this
level. The "business logic" side of the code should be completely
testable with a mock API (with stubs for uploadFile, createAccount,
etc.), and should not need to touch a real database at all.

In the middle level where these primitives are implemented, that's where
you actually translate these high-level operations into SQL. If the
high-level API is well-designed, each operation should be pretty well
encapsulated and should not cause unexpected conflicts with other
operations.


[...]
> My code logic is a mix of file uploads which leads to saving file info
> into db. And some general queries... my worry has been adding a
> feature which might cause a regression in another rearly executed
> code...its feels like I have to test all features/rest calls after
> every major change. Don't know how others do this...when there's some
> tight coupling involved.
[...]

Sounds like you're not really doing *unit* testing anymore, but it's a
large-scale application-wide regression test.  For that, probably your
best bet is to create test databases and use external testing with a
mock network / test DB server. E.g., basically what the dmd testsuite
does today: a directory of input files and expected output files, and
some simple tools to automatically run through all of them.  You could
create a library of test cases that you run your program through before
release, to make sure nothing that has worked in the past will stop
working now.


T

-- 
If it breaks, you get to keep both pieces. -- Software disclaimer notice