-
Notifications
You must be signed in to change notification settings - Fork 2
Development FAQ
Here we collect questions and answers related to design/architectural/implementation decisions or the data model for future reference. Questions here are for the most part related to issues mostly interesting for people developing the system.
The service is primarily build for browsing the data archived by TestArchiver. Therefore the url schema should try to follow the semantics and hierarchy of the data.
/items/<id>/subitems/<id>/view?filter=on For example: /series/12/build/123/history or /series/12/build/123/suite/12/
Other consideration is that all urls should contain all the information needed to render any view. So in other words whatever the user is viewing, she should be able return to the same view with same filters by simply copying the current url and opening it again.
Items in the TestArchiver data model receive an integer id referring to that item (e.g. series -> series_id, test cases -> test_id, suites -> suite_id). Builds also receive an integer id but it is referred as build_number and it is only unique in that series. Build numbers are assumed to come in ascending order but may skip numbers.
Confusingly each build also has a build_id which is actually a string that will default to the build_number if it is not otherwise specified. The build_id is used to identify the build when it does not actually have a build number (that actually is a number) that could be used to tie the build to some external system such as CI builds. For example the build_id could be a commit hash or version of the system under test which would allow aggregating all the test results related to that specific version in the same build.
Repository is a term used to differentiate suites/test cases that belong to different projects. By default all tests are in default repository. If tests from multiple repositories/projects are archived, the tests can be marked belonging to different repositories with --repository option of TestArchiver.
The test archive that Epimetheus visualises only contains results from actual executions of test cases. In other words, the system has no knowledge of tests that have not been executed and their results archived. Nevertheless, the test archive identifies individual test cases or suites and links them to data about their individual executions.