Manage Tests
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)
note
The rest of this chapter makes better sense if you read What To Test first.
#
ProjectProjects 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.
#
FileA 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.
#
TestTests 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
.
#
VersionVersions 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.