Document How To Identify Why a Test Failed about marklogic-unit-test HOT 9 CLOSED

2. Manually run setup + test in qconsole

I don’t think we should recommend that. We should recommend a proper test harness and make using that easier than pasting into Query Console.

from marklogic-unit-test.

on point 2.

2. Use UI to run individual test
   • click open the failing test in the UI in order to view the stack trace which will show which test has failed.
   • be sure to uncheck teardown to view the state of the test data at the time of failure.

on point 4.

4. Use log statements and error logs to get insight into the run time (tip: if you are testing a REST extension, your test code may be running in a different application server as the application code)
   • would be great to have the debugger working here

from marklogic-unit-test.

We identified two main testing patterns in other discussions, which should be documented. These show people both how to debug test failures, and also how to do test-driven development in MarkLogic in the first place.

Fortunately MarkLogic is more functional and componentized than a typical Java project, making it very natural to test components in DHF in particular. Each of the following is a natural, test-able component.

• DHF plugins
• declarative mapper mappings
• TDEs
• Redaction configuration
• REST API transforms
• and the like. For someone using marklogic-unit-test (preferred) the way to actually test and debug is to either

1. Edit and review in an interactive cycle

   • Edit the tests in some editor
   • Have "gradle mlWatch" running so those edits are pushed immediately
   • Have the testing web page open ( http://localhost:8042/test/default.xqy ) to run one test, or many there
   • Have the log file for your app server open (8042_ErrorLog.txt) so you can see new log statements that you add/tweak

2. Manually run setup + test in qconsole

   • do an xdmp.invoke(of the setup) - it can't run from qconsole because the module location it is run from matters.
   • run the test in qconsole, and return/log interesting info, or tweak the test in real-time in qconsole

from marklogic-unit-test.

I agree with @jmakeig. I don't think reproducing the test context in Query Console is the right long term approach. Query Console is a great place to investigate the database state after a test run, but it's not a well suited run time for tests that may have complex setups and interdependencies.

from marklogic-unit-test.

With my IntelliJ XQuery plugin, I am planning on adding support for running marklogic-unit-test based tests using the test runner framework to handle setup/teardown. These would provide the same workflow and UI/UX as the JUnit based tests.

I'm also planning on adding debugging support for MarkLogic queries, allowing you to debug any issues.

I have support for running (and profiling) queries in MarkLogic in the 1.4.1 version for IntelliJ 2019.1. Using the "Active editor file" option for the query file, I can currently run tests that don't have any setup/teardown requirements.

Errors are displayed in the output with the values from the assert and the stack trace of the function calls. This does not currently link to the files in the editor (like with Java stack traces), but this is something I am looking to implement.

from marklogic-unit-test.

My go-to for figuring out which test failed is to dive into build/test-results/marklogic-unit-test and look at the TEST-*.xml files.

from marklogic-unit-test.

This would be a good addition to our new docs.

from marklogic-unit-test.

DEVEXP-554

from marklogic-unit-test.

Closing, will be part of 1.4.0, tracking via DEVEXP-554.

from marklogic-unit-test.