Closed junedev closed 1 year ago
CC @taiyab @kntsoriano
Currently, we are not displaying multiple tests at the moment.
The way we read the test config in the website is probably just out of sync. If the test config was designed to accept an array, I will update the website to display everything in that array.
We display the tests inside a pre tag. It should just be a matter of iterating through the array and printing each test in its separate pre tag.
The way we read the test config in the website is probably just out of sync. If the test config was designed to accept an array, I will update the website to display everything in that array.
The test config is indeed designed as an array.
We display the tests inside a pre tag. It should just be a matter of iterating through the array and printing each test in its separate pre tag.
That would be great.
Cool :) I'm assigning myself to this now.
I've looked at this again, and currently, we don't display the tests in the editor view unless the user runs the tests. I think that it should be better to include the file within files.editor
so it will show up as a exercise file in the left side. What does everyone think?
I've looked at this again, and currently, we don't display the tests in the editor view unless the user runs the tests. I think that it should be better to include the file within files.editor so it will show up as a exercise file in the left side. What does everyone think?
In this case, I don't think we necessarily want that file in files.editor
, as the student doesn't really need to know about that file when working on the exercise. That file is just there for the purposes of running the tests. That we only show it in the tests view is fine.
We display the tests inside a pre tag. It should just be a matter of iterating through the array and printing each test in its separate pre tag.
I think this is how this should be done.
The tests tab should show on the right for all Practice Exercises, but it doesn't show for Learning Exercises.
For reference, these are the tracks/exercises that have more than 1 test file:
Track | Exercise | Number of test files |
---|---|---|
java | clock | 3 |
java | simple-cipher | 3 |
kotlin | clock | 4 |
python | paasio | 2 |
rust | forth | 2 |
This information was gathered by the following jq
script:
find ~/exercism/*/exercises/*/*/.meta/config.json -exec jq -c -r '{file: input_filename, tests: .files.test | length}' {} \; | grep -E -v '"tests":(0|1)'
Huh. I was unaware that passio had two test files (or had forgotten).
I know that for the concept exercise cater-waiter
we do indeed have extra test data files -- added to the editor
tag as @junedev mentioned above. And I think we may end up having more exercises with that format, since its really helpful to separate lengthy test data out from the exercises that use it.
Just to clarify: In addition to Eriks stats, Go has lots of exercises with 2 test files but they don't show up in the script because we put the 2nd test file in the editor key as a workaround.
In the Go track we have some exercises that contain two test files, one with the actual test code and one for the test data table (cases_test.go).
Since students had issues solving some exercises without seeing the cases file on the website, we added it to the files.test key in the config.json of the website. However, the cases file did not show up on the website.
We were wondering whether the website actually supports multiple test files. As a workaround we added the cases file to files.editor instead as it was done in the Python track.
If multiple test files are indeed not supported currently, I want to say that at least for the Go track we are planning to remove the cases files anyway in the future so we wouldn't need that feature anymore.
In any case, if listing multiple files under files.test will not work for some time to come, it might make sense that configlet throws an error that says to add additional files to files.editor instead.
If multiple test files are supported in the website already, then this issue can be closed as the bug was probably just related to the update process issue tracked in #6010.