Open barnes7td opened 8 years ago
+100 to this, we definitely need to consider multi expects per test an anti-pattern.
Discussed before in:
This has been a gripe of mine for a long time. It was really a pain point for the canIGet
function, which no matter which of the ~15 tests failed, it would always say "Should return the correct value" or something to that effect.
For Example:
Javascript Primer - Conditionals - Exercise 5 excerpt:
If this fails the student has very little means to figure out which of the
expect
s that failed. All the student can see is:Even if the student can effectively use
console.log
, we separate the console output from the spec output, so the student has no way to create a sequence where the console logs the combination and the test fails.It is also considered best practice to only have 1
expect
per test. IMO, we are teaching bad practice.But the greater issue is that we are making it difficult to impossible for students to get the feedback they need or systematically pass tests. Idealy, the tests would work in a TDD style approach, leading the student in logical steps to working code.
This is one of those issues that I have brought up on GitHub for multiple years on Bloc problems. It keeps creeping back in as a problem. This IMO, needs to be a standard (1 expect per test), that is required for acceptance to the curriculum.
There are times, when 2 expects (ie. test before and after a condition) are useful, or even necessary. But we will not likely face that much in the coding problems we are writing.
For the exercise listed, we must make this change, as it is impossible, for a student to fully debug, with the given tools.