UnitTestDatabaseLogic
Your trail: ReReStartingHaskellLoginHelpUseJsFiddleSearchPageHelpVSCodeSetupUpgradeLinuxVSCodeSetupLambdaFunctionsInHaskellUpgradeLinuxVSCodeSetup

This page (revision-4) was last changed on 07-Oct-2019 18:35 by john  

This page was created on 02-Oct-2019 20:32 by unknown

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

History

Version Date Modified Size Author Changes ... Change note
4 07-Oct-2019 18:35 2 KB john to previous
3 02-Oct-2019 20:39 1 KB john to previous | to last
2 02-Oct-2019 20:34 1 KB john to previous | to last
1 02-Oct-2019 20:32 1 KB unknown to last

Page References

Incoming links Outgoing links
UnitTestDatabaseLogic
UnitTestDatabaseLogic

Difference

Difference between version and

At line 1 removed one line
At line 3 changed one line
Automated/unit/integration testing...Need data setup & teardown.Might be multiple tables with foreign key constraints.  When we insert the data, we'll get new keys, so we need to remember the keys generated.Teardown: might be "delete the data" or might be "just leave it for the next test" or might be "delete SOME of the data" (which might have been generated by the test and not part of the setup).Setup note: if teardown isn't "delete the setup data", then the setup should be more like "find the data from the last test run or create it"."Find the data from the last test run" would probably look like "find config data matching the following list of requirements" (followed by the requirements).Requirements might be: rows having a given set of column values (or ranges of values); related records (e.g., children or parents) have certain column values or cardinalities (no children, exactly one child,2+ kids, exactly n kids, etc.)Setup might be specified as simple column values for rows, with children/related records having FK relationships.OR... might be specified as sproc names with parameter values (e.g., config-writing sprocs). Those sprocs are not under test and are assumed to be working properly. (Although they could have their own associated tests.)
Automated/unit/integration testing...Need data setup & teardown.
Might be multiple tables with foreign key constraints. 
When we insert the data, we'll get new keys, so we need to remember the keys generated.
Teardown: might be "delete the data" or might be "just leave it for the next test" or might be "delete SOME of the data" (which might have been generated by the test and not part of the setup).
Setup note: if teardown isn't "delete the setup data", then the setup should be more like "find the data from the last test run or create it".
"Find the data from the last test run" would probably look like "find config data matching the following list of requirements" (followed by the requirements).Requirements might be: rows having a given set of column values (or ranges of values); related records (e.g., children or parents) have certain column values or cardinalities (no children, exactly one child,2+ kids, exactly n kids, etc.)
Setup might be specified as simple column values for rows, with children/related records having FK relationships.
OR... might be specified as sproc names with parameter values (e.g., config-writing sprocs). Those sprocs are not under test and are assumed to be working properly. (Although they could have their own associated tests.)
Finally, you might need to specify APIs to be called, along with parameter values. That's basically code to be run. For that, maybe we just specify a chunk of code to be compiled (C#? Java? Python? Javascript?) and a directory of dependencies (DLLs, jar files, etc.). Of course, at this point, why would we do this in a config file when we have an editor and compiler already at hand, since we're developers coding up automatic tests?
So, we might need to find ''some'' data and then code up some other related data (so, we'd need to use data item names or ids after lookup to create related data).
Could use regular expressions or LIKE expressions to find data.
Creating data for setup could also include a confirmation that the teardown will work properly. (Or do we need that?). Return number of objects (rows?) created, and in teardown, if we don't delete exactly what we created, log a loud warning.
I would specify all this in XML.
This page (revision-4) was last changed on 07-Oct-2019 18:35 by john   Top

About
Help
SysInfo

(page = LeftMenu)

Admin

(page = LeftMenuFooter)

JSPWiki v2.10.2  
JSPWiki v2.10.2