Repository navigation
Parameter order in assertEqual() statements #440
Description
We have both ways of ordering the parameters actual, expected result of the assertEqual() method.
While the Python implementation uses indifferent names (first, second - code) all examples use the order actual followed by expected (python doc – basic-example).
self.assertEqual('foo'.upper(), 'FOO')
self.assertEqual(s.split(), ['hello', 'world'])I think it would be better to be consistent within this track. As I personally don't have any preferences I would just follow the official python documentation examples and default to self.assertEqual(actual, expected).
Activity
pheanex commentedon Mar 22, 2017
(actual, expected) looks good to me. I am in favour of consistency.
rootulp commentedon Mar 22, 2017
I think conforming to the Python doc basic example is a god idea. (Actual, expected) seems right.
Refactor assertEqual(actual,expected) param order
Refactor assertEqual(actual,expected) param order
Refactor assertEqual(actual,expected) param order
protein-translation: adjust assertion param order (exercism#440)
protein-translation: update tests to v1.1.0 (#1329)
nikclayton commentedon Feb 20, 2019
FYI -- if you run the tests in PyCharm (as I'm doing with my students) PyCharm shows the Expected/Actual results in the wrong order. The JetBrains bug for this behaviour is https://youtrack.jetbrains.com/issue/PY-27267.
cmccandless commentedon Feb 20, 2019
@nikclayton thank you for adding that info here.
We've run into that issue before here, but it's good to document it as a known issue.