We’re shown the assertion that was run. That includes the input (in this case nothing), my actual output of 'foo', and the expected output of 'One for you, one for me'
Well, yeah, but such view only for failed (if im not mistaken). When some tests passed, some dailed, for first you can see only code run. I (personally, maybe im the only one) want to see how previous tests run as well. Easier to understand what’s correct, what’s not, when you see which data it proccess correct, which is not.
For SQL tasks, there is nothing for passed tasks at all
Would be awesome to see table, bc you are actually working with one, but this will do as well. At least some info in passed task, for now im just cecking tests code, to see what data passes, what’s not
Once things are set up locally, you can investigate the pytest-replay and pytest-history plugins, which both keep previous test runs and offer comparisons between previous runs and the current run. You can also view cached runs by running pytest --cache-show on the command line without using plugins.
Well, yeah, but such view only for failed (if im not mistaken).
In my experience, this is how the majority of test frameworks work in many programming languages. They only show detail on the tests that fail by default. However, many test frameworks do offer plugins or modes where you can see all failed and passed tests in a test report or summary.
For Pytest, if you run it locally with the -v option, it provides a running tally out to the command line of what has passed and what has failed.
Exercism has a specific API that all test runners on all tracks follow. This API doesn’t allow for the display of previous test runs. All runners on all tracks are spun up in Docker containers and each test run is independent from the one before. We don’t save the test results anywhere on the backend (things you see in the editor are cached in the browser, but not saved in the DB). We only save info once a student “submits” their solution, which only happens after all tests pass.
Note you can also see the test code/file in practice exercises to see what’s run. Fitting test data into tables can be … tricky as a lot of the test data is structured objects and not simple values. Functions can be expected to raise exceptions, return multiple values, etc. The test runners are carefully crafted to show output in a useful manner.
In Exercism, the idea is to pass a test and move onto the next one until all tests pass. If an earlier test does break in the process, then you go back and fix it. The API Bethany linked to indicates the test runner isn’t required to provide additional information for a passing test. We don’t want to over-burden a student since they should be focusing on the next test.