I’m doing the Python track using PyCharm and it is interpreting the actual/expected values from the tests the other way around:
Is this a bug from PyCharm or are the values in the wrong order?
The unit test library just checks if two values are equal. I don’t believe there’s any hard and fast conventions about the order of first, second mapping to want, got. PyCharm appears to push a strong opinion on it’s users there.
See related Stack Overflow discussion
TL;DR: It’s a PyCharm bug. One of several that’s have been open (related unittest one) for … 5 years or more? (there is even one for unittest that was opened 12 years ago!). The issue periodically crops up and they refuse to fully fix it and continue to blame “third party vendors” for the problem.
@IsaacG is correct - technically, there isn’t an enforced order for either pytest or unittest. Both tools are designed with knobs that control mapping and output, so they ultimately leave it to the test writers to deal with ordering and labeling. Which means consistency within tests becomes really important.
However, starting about 13 years ago, the core Python team decided that the documentation and examples for unittest would follow the form actual, expected, which means there’s a lot of “tradition” there - and a lot of test cases that follow that pattern. Additionally, Pytest performs some introspection to give more detail about what is going on that uses the form actual, expected. It gets overridden if the test writer sets an explicit message or label or report format, but it is there by default.
PyCharm now has settings in the UI to swap the values - but that only works for PyTest style tests - not tests where PyTest is picking up unittest test cases or doctests, IIRC. It also causes other issues with pytest.
As is stated in the comments from the SO post, support for Pytest and Unittest in PyCharm is pretty bad. Overall, they are quite hostile to open source and third party tooling.
I mostly use an attached/embedded docker container for running tests, and/or the command line (either through the integrated terminal, or a stand-alone terminal.).
2 Likes
Thanks for the explanation! Really odd that they go against the conventions.
They do the same for Go with Goland 
Everyone uses gofmt to format the code and has the editor setup to format on save. In Goland, they took ages to ackowledge a nice config for “format on save” is probably needed, and they insist on using their own formatter instead of gofmt by default.
1 Like