Closed tomasbedrich closed 2 years ago
Inheritance + mocking + Betamax cassettes proved itself to be too wild combination to maintain. Therefore I would rather get rid of classes at all, but if the only thing which remains is unittest.TestCase
base class, I'm fine with that.
Re assert
: it's a subjective preference. I like it because it's shorter than self.assertXxx
, I don't need to remember special Xxx
and Yyy
for every type of assertion. And it plays well with pytest style tests (=simple top level functions).
Re subtest: Thanks, I haven't knew about that plugin! Anyway, I would rather get rid of subtests (and eventually turn them into pytest parametrized tests). The motivation is for subtests not to influence each other's state.
To sum it up and maybe provide some underlaying motivation: I am using pytest
in my daily job for multiple years without any issues. 😄 Therefore I tend to reorganise tests the way I know they will work.
Sorry that not all my arguments are objective.
Thanks for your review.
Thanks for the explanations. Yes, it probably is a matter of taste and style incorporated in the daily workflow. For me class-based tests make it easier to detect test groups and the unittest asserts are more verbose in my opinion. We use pytest at work as well, but with some custom collection logic to be able to run some read-only tests on production systems. I am not fixed to any approach - as long as it works, I am fine with it, I asked just for curiosity. ;)
Fixes #133, #162 + addresses Travis note from #163.
The core motivation is that I am not able to fix login tests for #162, because I don't understand what's happening there.
It is too big bite for anyone to migrate all tests at once. Therefore I tried to kick off a new structure using a modern tools, which seems simpler to use for me. I can imagine us incrementally migrating old tests to
tests_new
over time.