search

gklyne / annalist

Free-form web data notebook - "Data management for little guys"
MIT License
25 stars 3 forks source link

View tests are getting complex and difficult to maintain #33

Open gklyne opened 10 years ago

gklyne commented 10 years ago

Review and tidy Identify duplicated test cases; eliminate duplication Identify over-complex test cases, split down into simpler test cases

gklyne commented 10 years ago

A big source of complexity is in the generic edit view tests, where (for historical reasons) the Type_view form is used, even with non-type data. This is associated with type and URI handling logic that complicates the main purpose of the tests, and should be tested separately by the test_recordtype modules. Replace all references to Type_view with some other view, and use non-type data throughout. Check that test_recordtype handles the corresponding type data tests.

In the process, module tests.testentitydata should be significantly simplified.

A series of edits around commit 8735d4d5b5c7936396f817172642c0bc2f692746 touch on this area (revising stored URIs, which tangle with type URIs in the current structure).

gklyne commented 9 years ago

The new test module 'testsitedata' starts to address this by providing a single module too validate the built-in site data. Over time, other tests which do no more than test the site data can be removed from existing tests. See commits leading up to 6d75e54.

gklyne commented 6 years ago

Substantial revisions to test logic in release 0.5.9, starting process of isolating view context structure details in a small number of support functions. Some tests are still be to converted to use this approach.