Bringing your track in line with the latest changes to Problem Specifications#916
Bringing your track in line with the latest changes to Problem Specifications#916petertseng merged 8 commits intomasterfrom
Conversation
|
todo: process these entries |
|
exercises for which no change is needed, and the reason why: palindrome-products: we're using Nothing to signify are no palindromes. upstream 1.1.0 -> 1.2.0 exercism/problem-specifications#1430 exercises where a change is needed: |
|
for tests that we intend to never add, we should leave them in the tests.toml but mark them as false. for tests that we intend to add but haven't gotten around to yet, we should remove them from tests.toml so that tools that detect whether a test is present in tests.toml will properly detect that it isn't there and will ask us to explicitly include or exclude it |
petertseng
left a comment
There was a problem hiding this comment.
With these commits I have added (I suggest to squash when merging), all .meta/tests.toml files now correctly reflect the state of this track, so I can safely approve this.
For CI to pass, it is necessary for a maintainer other than myself to approve #917 , at which point this PR needs to be rebased on master.
89f902d to
8dd3ef7
Compare
|
I've approved and merged #917. I've also rebased this PR onto master. |
individual comments explain
8dd3ef7 to
5a0fd58
Compare
|
rebasing on #929 |
We're in the process of re-opening the Problem Specifications repo, as discussed in this issue.
This PR adds
.meta/tests.tomlfiles for all exercises for which canonical data is defined in the Problem Specifications repo.We'll now discuss why we're making this change.
Keeping track of implemented tests
While most of the changes to the Problem Specifications repo are specific to that repo, there is one track-specific change:
In this case, the track has chosen to implement two of the three available tests.
If a track uses a test generator to generate an exercise's test suite, it must use the contents of the
tests.tomlfile to determine which tests to include in the generated test suite.Tooling
To make it easy to keep the
tests.tomlup to date, tracks can use thecanonical_data_syncerapplication.This application is a small, standalone binary that will compare the tests specified in the
tests.tomlfiles against the tests that are defined in the exercise's canonical data.It then interactively gives the maintainer the option to include or exclude test cases that are currently missing, updating the
tests.tomlfile accordingly.To use the canonical data syncer tool, tracks should copying the
fetch-canonical_data_syncerand/orfetch-canonical_data_syncer.ps1scripts into their repository.Then, running either of these scripts will download the latest version of the tool to the track's
bindirectory.The tool can be run using
./bin/canonical_data_synceror.\bin\canonical_data_syncer.exe, depending on your operating system.Changes
In this PR, we're adding
meta/tests.tomlfiles for all the exercises for which canonical data is defined.We've initially marked all tests as included, which means that we'll assume that your track has implemented those tests.
If there isn't anything obviously wrong with the PR, I would suggest to merge this PR first, and then later on update the
meta/tests.tomlfiles according to your track's actual implementation.