The way Outomated manages tests is similar to how developers keep tests using projects and files in a file system. Lets understand the logical file structure in Outomated:
Project└── File1 └── Test1 └── Version1 └── Version2 (latest) └── Test2 └── Version1 (latest) └── Version2 File2 └── Test1 └── Version1 └── Version2 (latest) └── Test2 └── Version1 └── Version2 (latest)
The rest of this chapter makes better sense if you read What To Test first.
Projects in Outomated are the top level grouping for files, tests, build capabilities, builds and variables. They may keep files and tests for a module (of an application) or an application itself. For instance, in a note taking application, some modules like
Note editor and
Searching notes could be separate projects.
A File is used to group tests with similar objective. For instance, in a note taking app's 'note editor' module,
Markdown Format Tests could be a file having tests for only testing the behavior of writing notes in markdown.
Tests are created to validate behavior of application features and functionalities. A Test may be created for a smallest possible feature or functionality in some part of an application module. For instance, in a
Markdown Format Tests file, some of the tests could be,
validate user mentions suggest users or
validate external links are properly linked.
Versions are snapshots of a test. When a new test is created, a default 'first' version is automatically created which is the actual container of the test code. Whenever you feel like making some significant refactoring to test code, creating a new test is a good idea so that you can keep the last 'running' version aside and make changes as new version. The newly added version becomes the 'latest' version. While running builds, any version from a test can be included in the build.
If at any point in time, you need to revert to previous version, create a new version and use code form the desired version.