Comments (7)
I'm curious what your proposed solution would look like.
from marklogic-unit-test.
PR #139.. make sure to read the comment.. ;)
from marklogic-unit-test.
@dmcassel, WDYT?
from marklogic-unit-test.
@dmcassel, WDYT?
Sorry, been swamped. Trying to get to this.
from marklogic-unit-test.
There's definitely good value here, as the user need of "Load some data (in a separate transaction) before this test runs" is common - there's a good bit of plumbing in the DHF marklogic-unit-test tests to do exactly that. And that's different from the user need of "Load these documents before any tests run so that they're available for all tests" - mlDeploy can satisfy that need via e.g. src/test/ml-data. But that's a separate need.
I'm wondering though if there's an easy button to provide for users so that they can avoid multi-statement XQuery modules? Those are a bit more complex and run counter to the current pattern of "Look in the setup/teardown modules to find setup/teardown stuff".
For example, here's what a setup.xqy module looks like in DHF that both clears out some data and loads some test-specific data:
xquery version "1.0-ml";
import module namespace hub-test = "http://marklogic.com/data-hub/test" at "/test/data-hub-test-helper.xqy";
hub-test:reset-hub();
xquery version "1.0-ml";
import module namespace hub-test = "http://marklogic.com/data-hub/test" at "/test/data-hub-test-helper.xqy";
import module namespace test = "http://marklogic.com/test" at "/test/test-helper.xqy";
hub-test:load-artifacts($test:__CALLER_FILE__),
hub-test:load-jobs($test:__CALLER_FILE__)
I think multi-statement setup modules are fine because we don't have to parse out what's the setup logic and what's the actual test logic.
What seems even better though is if MLUT just loaded the data (if detected for a particular test module) automatically via separate transactions. Then the user doesn't need any new code - they just add their data files and collections/permissions and they're off and running.
from marklogic-unit-test.
How about the following: setup/teardown are invoked between each test case, right? What if you would receive the test case (file) name as a parameter, so that you can decide how/what to setup/teardown. I could easily get rid of the multi statements in that case. Just haven't dug in, to figure out what is needed for that.
As a bonus, you could use sjs as well in that case, since multistatements are not possible in sjs, without resorting to evals/invokes.
The helper functions I created in PR #139 could then be invoked to help with loading/removing test case specific test data. They could probably use a little bit of polishing, but we have been using them for over a year now, and are very happy with it so far.
from marklogic-unit-test.
I'm closing this for now until a request like this pops up again. With the docs we have for loading data, I think this is already pretty easy for a user to do - just toss some basic code into the setup or suite setup, where it's also easy to configure permissions and collections. We'd need to invent a way otherwise for permissions/collections to be configured for the test-data documents.
Also, my preference is not to delete data after a test ends - that allows for easier debugging if the test fails, as well as manual inspection of how data was modified. I prefer for data to be deleted before a test begins instead.
from marklogic-unit-test.
Related Issues (20)
- Upgrade Java Client and other dependencies HOT 2
- Use recommended Gradle configurations instead of deprecated ones HOT 1
- test:get-caller breaks when you use a test suite lib that wrappes test-helper HOT 1
- Helper function to log errors in a readable way HOT 1
- DeployOtherServersCommand.java missing from DataHub 5.x HOT 2
- Document out of date HOT 3
- mjs files aren't recognized as test files
- Bump Java Client to 6.0.0
- Documentation shows incorrect namespace for import
- XDMP-TOOMANYARGS when passing more than two nodes to test:assert-exists() helper function HOT 2
- Update rest endpoint result with codecoverage information and add number of succeeded and failed tests in default output HOT 2
- Enable providing custom code coverage module HOT 2
- timeout on dbg:wait should not be fixed on 10 second HOT 3
- Add nr of failed and succeeded tests per test case
- change 'Tests Run' and 'Passed' to reflect the number of testcases instead of the number of assertions HOT 2
- Improve readability on testreports in cicd pipelines HOT 2
- dead link in docs HOT 2
- Wiki Page is empty HOT 1
- Nested test suites may lead to incorrect setup module selection HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from marklogic-unit-test.