I’m trying to sync the Rust track’s version of protein-translation with problem-specifications. The canoncial description lists the following codons and their translations:
Codon
Protein
AUG
Methionine
UUU, UUC
Phenylalanine
UUA, UUG
Leucine
UCU, UCC, UCA, UCG
Serine
UAU, UAC
Tyrosine
UGU, UGC
Cysteine
UGG
Tryptophan
UAA, UAG, UGA
STOP
However, there exist more codons. In particular, lysine maps to the codons AAA and AAG. But there is a test case in canonical-data.json against “invalid” codons, but the string "AAA" is used for it:
{
"uuid": "1e75ea2a-f907-4994-ae5c-118632a1cb0f",
"description": "Non-existing codon can't translate",
"comments": [
"It's up to a track how to behave when a non-existing codon is ",
"passed; to simplify the exercise, this test may be excluded in ",
"order to remove the requirement for input validation. "
],
"scenarios": ["input-validation"],
"property": "proteins",
"input": {
"strand": "AAA"
},
"expected": {
"error": "Invalid codon"
}
},
The example solution on the Rust track fails this test case, because it correctly maps "AAA" to lysine. Due to how the exercise was designed, I can fix that on the Rust side without breaking any existing solutions. (The codon to protein mapping is an input to the students submission. So, a submission should still work even with a technically incorrect input mapping.)
However, maybe it would be better to fix the test with the reimplements mechanism? What do you think?
Ah, I was just hit by this on the C track. I think this test is in contradiction with the following paragraph from the description (emphasis mine):
There are 64 codons which in turn correspond to 20 amino acids; however, all of the codon sequences and resulting amino acids are not important in this exercise. If it works for one codon, the program should work for all of them. However, feel free to expand the list in the test suite to include them all.
So, to me it clearly says we can implement the full mapping if we’d like, even if that’s not required and our solution will still pass the tests if we only use the partial list at the end of the description.
Now, this contradiction could either be resolved by removing the test, or by changing the description. IMO we should preserve the description and change/remove the test because:
I think I’d add a new test so we can mark it as reimplementing AAA. Can a test reimplement both AAA and XYZ? They test different things now, but the proposed replacement for AAA will be testing the same thing as XYZ.
If we retroactively mark XYZ as reimplementing AAA, that might be confusing on tracks that already have both tests. That’s why I would like a new test reimplementing either AAA or both XYZ and AAA.
Yeah, that’s my preference. I was just wondering if it’d be confusing to maintainers that an existing test now reimplements a test when it previously didn’t.
(on 
