Overview
Determine:
- What supported shells unit test coverage already exists for.
- Level of unit test coverage for each shell that unit tests exist for.
Write issues to cover gaps in unit test coverage of business logic and supported shells.
Details
Unit Test Coverage
When unit test coverage of a file is not effectively 100%, then write an issue to write unit tests for that file. Note that there already exists a story for creating unit tests for shellFunctionSetup.sh, so that file is except from this work.
Do not write unit tests as a part of this work.
Supported Shell Coverage
When unit test coverage of a file is effectively 100%, but tests are failing for a specific shell, then write an issue to rectify this. This could mean fixing the unit tests, or the underlying business logic. Do not fix the failing tests as a part of this issue.
When unit tests don't exist at all for a supported shell, write an issue for adding unit test coverage for that shell to that file. If there is no unit test coverage for a shell at all, then one issue should be written for adding unit test coverage for that shell for each file in the repository that needs unit test coverage. This is likely to result in the creation of a lot of issues.
Supported Shells
- bash
- zsh
- dash
- BusyBox ash
- FreeBSD sh
- NetBSD sh
- mksh
- OpenBSD ksh
- yash
- posh
- OSH
Artifact(s)
- One GitHub issue for each file that requires additional unit test coverage for a specific shell:
- For example, if
fileA need additional unit test coverage for zsh, dash, & bash, then three issues should be created.
Scope
This issue is for evaluating unit test coverage, not for adding or evaluating what unit tests are run by the pipeline. Having said this, note that if issue #3 has been worked, then all unit tests should be run by the pipeline. If this is not the case, then an issue should be written to cover this work.
This issue is also also not for adding GitHub status badges.
This issue is for evaluation. The result of this issue should be the creation of other issues. The issues created by this issue should be linked back to this issue. No PR should be created by this issue because no code, unit test, or documentation changes should be made. If changes to any of those things are noted as being necessary, then an issue should be written to made said changes.
Blockers
This shale not be done until unit tests are added by issue #2.
This should be worked after the pipeline is created by issue #3.
This should be worked after GitHub status badges are added by issue #4 and #5. This is because that work is more important, not because it's blocking.
Overview
Determine:
Write issues to cover gaps in unit test coverage of business logic and supported shells.
Details
Unit Test Coverage
When unit test coverage of a file is not effectively 100%, then write an issue to write unit tests for that file. Note that there already exists a story for creating unit tests for
shellFunctionSetup.sh, so that file is except from this work.Do not write unit tests as a part of this work.
Supported Shell Coverage
When unit test coverage of a file is effectively 100%, but tests are failing for a specific shell, then write an issue to rectify this. This could mean fixing the unit tests, or the underlying business logic. Do not fix the failing tests as a part of this issue.
When unit tests don't exist at all for a supported shell, write an issue for adding unit test coverage for that shell to that file. If there is no unit test coverage for a shell at all, then one issue should be written for adding unit test coverage for that shell for each file in the repository that needs unit test coverage. This is likely to result in the creation of a lot of issues.
Supported Shells
Artifact(s)
fileAneed additional unit test coverage forzsh,dash, &bash, then three issues should be created.Scope
This issue is for evaluating unit test coverage, not for adding or evaluating what unit tests are run by the pipeline. Having said this, note that if issue #3 has been worked, then all unit tests should be run by the pipeline. If this is not the case, then an issue should be written to cover this work.
This issue is also also not for adding GitHub status badges.
This issue is for evaluation. The result of this issue should be the creation of other issues. The issues created by this issue should be linked back to this issue. No PR should be created by this issue because no code, unit test, or documentation changes should be made. If changes to any of those things are noted as being necessary, then an issue should be written to made said changes.
Blockers
This shale not be done until unit tests are added by issue #2.
This should be worked after the pipeline is created by issue #3.
This should be worked after GitHub status badges are added by issue #4 and #5. This is because that work is more important, not because it's blocking.