Requirements
High Priority
Frontpage(s)
Guides
Contributing Pages
UX/Responsiveness
Low Priority
General
Responsiveness
Guides
Reference Pages
Contributing Pages
Support Pages
With the refactoring in #181 being nearly complete, we should think about also a new documentation that supports all of the existing testdeck integrations.
While every package must have its own README.md, this part of the documentation should focus on the integration alone and refer the user to a common set of documents that will reside at the top level of the mono repo. That way we can still make use of the built in github site functionality.
Domain
The current documentation can be accessed via the mocha-typescript.org domain.
A quick look shows that testdeck.org is still available. Maybe we should use this in the future?
testdeck README.md
This documentation should provide the user with information on the available packages and how to participate in the development a/o building things locally, or even provide new integration packages for other test frameworks that we have not considered yet.
testdeck integration package README.md
This documentation should provide the user with information on how to use a specific integration of testdeck, e.g. @testdeck/mocha with their favourite test framework.
From here, pointers will lead the user to more detailed information in the common documentation.
Also, we have to rework the badges (npm/ci/...).
testdeck seed README.md
The seed's documentation should focus on how to get things running with that particular seed. Provides pointers to testdeck documentation.
Common documentation testdeck/docs
We must remove any reference to mocha-typescript or mocha and make this so that it will give the user information on whether a specific testdeck feature is available for a specific integration, e.g. slow is available on @testdeck/mocha but is ignored/not supported on e.g. @testdeck/jest, and so on.
Also, we have to remove the badges from all documents as these will no longer work.
My initial proposal for the structure would be so, e.g. under testdeck/docs/ one can find the following documents
- index.md
Provides the user with pointers to the existing other documents. Gives an overview over the available features and integrations for the various test frameworks. Some marketing stuff. Also provides links for each integration package on npm and github.
- api.md
A general overview of the API.
- suites.md
Focuses on suite declaration alone, including execution modifiers, lifecycle (aka hooks), and suite settings (slow, timeout, ...).
- tests.md
Focuses on test declaration alone, including execution modifiers, lifecycle (aka hooks), and suite settings (slow, timeout, ...).
- parametrised_tests.md
Focuses on parametrised test declaration alone, including execution modifiers, lifecycle (aka hooks), and suite settings (slow, timeout, ...).
- generated_suites.md
Focuses on dynamic generation of suites. Shows how to combine the standard test UI (describe/it) with the object oriented approach.
- dependency_injection.md
Focuses on dependency injection alone.
- contributing.md
Focuses on contribution guide lines, e.g. how to file bug reports, make pull requests and thus participate in the development and so on.
- framework_integration.md
Focuses on how to integrate additional test frameworks with testdeck, based on an existing integration, e.g. mocha.
- di_integration.md
Focuses on how to integrate additional ioc / dependency injection frameworks, based on an existing integration, e.g. di-typedi
More?
Requirements
High Priority
Frontpage(s)
Guides
Contributing Pages
UX/Responsiveness
Low Priority
General
Responsiveness
Guides
Reference Pages
Contributing Pages
Support Pages
With the refactoring in #181 being nearly complete, we should think about also a new documentation that supports all of the existing testdeck integrations.
While every package must have its own README.md, this part of the documentation should focus on the integration alone and refer the user to a common set of documents that will reside at the top level of the mono repo. That way we can still make use of the built in github site functionality.
Domain
The current documentation can be accessed via the mocha-typescript.org domain.
A quick look shows that testdeck.org is still available. Maybe we should use this in the future?
testdeck README.md
This documentation should provide the user with information on the available packages and how to participate in the development a/o building things locally, or even provide new integration packages for other test frameworks that we have not considered yet.
testdeck integration package README.md
This documentation should provide the user with information on how to use a specific integration of testdeck, e.g.
@testdeck/mochawith their favourite test framework.From here, pointers will lead the user to more detailed information in the common documentation.
Also, we have to rework the badges (npm/ci/...).
testdeck seed README.md
The seed's documentation should focus on how to get things running with that particular seed. Provides pointers to testdeck documentation.
Common documentation testdeck/docs
We must remove any reference to mocha-typescript or mocha and make this so that it will give the user information on whether a specific testdeck feature is available for a specific integration, e.g.
slowis available on@testdeck/mochabut is ignored/not supported on e.g.@testdeck/jest, and so on.Also, we have to remove the badges from all documents as these will no longer work.
My initial proposal for the structure would be so, e.g. under testdeck/docs/ one can find the following documents
Provides the user with pointers to the existing other documents. Gives an overview over the available features and integrations for the various test frameworks. Some marketing stuff. Also provides links for each integration package on npm and github.
A general overview of the API.
Focuses on suite declaration alone, including execution modifiers, lifecycle (aka hooks), and suite settings (slow, timeout, ...).
Focuses on test declaration alone, including execution modifiers, lifecycle (aka hooks), and suite settings (slow, timeout, ...).
Focuses on parametrised test declaration alone, including execution modifiers, lifecycle (aka hooks), and suite settings (slow, timeout, ...).
Focuses on dynamic generation of suites. Shows how to combine the standard test UI (describe/it) with the object oriented approach.
Focuses on dependency injection alone.
Focuses on contribution guide lines, e.g. how to file bug reports, make pull requests and thus participate in the development and so on.
Focuses on how to integrate additional test frameworks with testdeck, based on an existing integration, e.g. mocha.
Focuses on how to integrate additional ioc / dependency injection frameworks, based on an existing integration, e.g. di-typedi
More?