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