RunestoneInteractive / RunestoneInteractive/thinkcspy

The "Expected" and "Actual" labels on autograded assertions for ActiveCode exercises are backwards

Open
#276 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
135
Forks
197
PR merge metrics
No merged PRs in 30d

Description

Please check the current issues Many bug reports are duplicates, this just creates more work for us. Searching the issues first may give you your answer or a workaround! If not adding new information to an existing report is much more helpful than a new report.

What Course are you in
Knowing the course will help us a lot

hhtlacs

What Page were you on

What is your username
norkish

Describe the bug
A clear and concise description of what what you were trying to accomplish and what went wrong. Vague statements like X does not work are not helpful. Imagine if one of your students sent you an email that said, "My program doesn't work, whats wrong with it?" Could you help them with only that to go on?

When I create ActiveCode exercises and use the self.assertIn, the order of operands seems to want "expected" first and then "actual" second. But when the grader reports the test results and allows "Expanding Differences", these two labels are swapped (i.e., it shows the submission derived from the student's solution as the "expected" and the part that my test checks should be "in" as the "actual")

Traceback
If you got here through the Bug Report page and there was a stack trace, please paste it here

Javascript Errors
Many many errors can be quickly diagnosed from the Javascript Console error log. On Chrome this is View --> Developer --> Javascript Console, on Safari ⌥⌘i or Develop --> Show Web Inspector on Firefox Tools --> Web Developer --> Toggle Tools

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing an ActiveCode exercise using self.assertIn and inspect the grader's "Expanding Differences" output. Trace the assertion-result display entry point and add or update a regression test if one exists; done means the expected and actual labels match the operands shown in the grader.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
frontend, testing-qa
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.