4 ms·

I would highly recommend pytest. It's very simple, very pythonic. Here is for example my Hearthstone simulator, with ~600 pytest-compatible tests: https://gith

I would highly recommend pytest. It's very simple, very pythonic. Here is for example my Hearthstone simulator, with ~600 pytest-compatible tests: https://github.com/jleclanche/fireplace/tree/master/tests https://github.com/jleclanche/fireplace/tree/master/tests It's just plain asserts. You run it with `py.test`. Nothing simpler.

orf 10y ago
Nice sample of tests! I also love pytest, but one of the best things IMO is fixtures, which your tests don't seem to use? For those who don't know fixtures are a type of dependency injection. You just make a function (e.g game) in a file called conftest.py, and wrap it with a '@pytest.fixture'. Then any tests you write that have an argument named 'game' will have the result of the 'game' function passed as a value. So 'game' could return 'prepare_game()', and other fixtures can do the same with their arguments to build more complex fixtures. I find it saves a load of initialization code being repeated.
- nilliams 10y ago
  Fixtures are considered an anti-pattern by many as they over-DRY [0] your tests and obscure them by introducing 'Mystery Guests' [1]. [0] http://stackoverflow.com/a/11837973 http://stackoverflow.com/a/11837973 [1] https://robots.thoughtbot.com/lets-not#will-our-mystery-guest-please-leave https://robots.thoughtbot.com/lets-not#will-our-mystery-gues...
- scrollaway 10y ago
  Yeah, I don't actually make deep use of pytest functionality. The whole thing used to be runnable without pytest for ease of use (with a __main__ block finding and running all test() functions). I should definitely use fixtures - been meaning to! It's why I love pytest, you don't need to go deep into it to make a high quality test suite.
  - nilliams 10y ago
    Please don't move to fixtures, your tests are great as-is (thanks for sharing). See my comment above!
    - scrollaway 10y ago
      I agree with it and hold the same view, which is why I haven't moved to them yet. My plan was to get rid of the "game = prepare_game(...)" line that's present on every single test, and have the game be passed as an argument to the tests which AIUI pytest supports.
thristian 10y ago
Man, I never understood the love for py.test. People say "it's Pythonic, you just use asserts", but asserts aren't Pythonic. For one, asserts are removed when you run Python with "-O", so, uh, good luck running your test suite in that configuration. Secondly, crawling up the stack to inspect the bytecode to figure out what condition was actually asserted so you can print a nice error... that's the opposite of Pythonic. Sure, the unittest module in the standard library is a bit Java-ish, but it's much less magic, and I feel like keeping per-test state in a class that gets instantiated multiple times is more Pythonic than having everything be top-level functions. And of course unittest is in the standard library, which means that most apps and libraries are going to use it, most people are going to be familiar with it, so your app or library will be more approachable to co-workers and/or contributors if it's tested the same way. Heck, a lot of Python frameworks have their own test helpers built on top of unittest (hello, Twisted and Django!) so you don't get to choose anyway. You could write Python code with three-tab indents, but you should use 4-spaces like everybody else. You could write your own custom packaging and dependency management system, but you should use setuptools like everybody else. You could any number of custom test harnesses, but you should use unittest like everybody else.
- orf 10y ago
  > For one, asserts are removed when you run Python with "-O", so, uh, good luck running your test suite in that configuration Which is not something anyone has ever wanted. > Sure, the unittest module in the standard library is a bit Java-ish, but it's much less magic, and I feel like keeping per-test state in a class that gets instantiated multiple times is more Pythonic than having everything be top-level functions. It's really really unpythonic. It looks horrible and leads to messy tests. With pytest you get dependency injection via fixtures which cuts down on so much repetitive initialisation code. We've got both kinds of tests in our codebase, and the pytest ones are a lot nicer to write and refactor.
  - bpicolo 10y ago
    So unpythonic that it even uses camelcase.
  - 10y ago

orf 10y ago

Nice sample of tests! I also love pytest, but one of the best things IMO is fixtures, which your tests don't seem to use? For those who don't know fixtures are a type of dependency injection. You just make a function (e.g game) in a file called conftest.py, and wrap it with a '@pytest.fixture'. Then any tests you write that have an argument named 'game' will have the result of the 'game' function passed as a value. So 'game' could return 'prepare_game()', and other fixtures can do the same with their arguments to build more complex fixtures. I find it saves a load of initialization code being repeated.

nilliams 10y ago
Fixtures are considered an anti-pattern by many as they over-DRY [0] your tests and obscure them by introducing 'Mystery Guests' [1]. [0] http://stackoverflow.com/a/11837973 http://stackoverflow.com/a/11837973 [1] https://robots.thoughtbot.com/lets-not#will-our-mystery-guest-please-leave https://robots.thoughtbot.com/lets-not#will-our-mystery-gues...
scrollaway 10y ago
Yeah, I don't actually make deep use of pytest functionality. The whole thing used to be runnable without pytest for ease of use (with a __main__ block finding and running all test() functions). I should definitely use fixtures - been meaning to! It's why I love pytest, you don't need to go deep into it to make a high quality test suite.
- nilliams 10y ago
  Please don't move to fixtures, your tests are great as-is (thanks for sharing). See my comment above!
  - scrollaway 10y ago
    I agree with it and hold the same view, which is why I haven't moved to them yet. My plan was to get rid of the "game = prepare_game(...)" line that's present on every single test, and have the game be passed as an argument to the tests which AIUI pytest supports.

thristian 10y ago

Man, I never understood the love for py.test. People say "it's Pythonic, you just use asserts", but asserts aren't Pythonic. For one, asserts are removed when you run Python with "-O", so, uh, good luck running your test suite in that configuration. Secondly, crawling up the stack to inspect the bytecode to figure out what condition was actually asserted so you can print a nice error... that's the opposite of Pythonic. Sure, the unittest module in the standard library is a bit Java-ish, but it's much less magic, and I feel like keeping per-test state in a class that gets instantiated multiple times is more Pythonic than having everything be top-level functions. And of course unittest is in the standard library, which means that most apps and libraries are going to use it, most people are going to be familiar with it, so your app or library will be more approachable to co-workers and/or contributors if it's tested the same way. Heck, a lot of Python frameworks have their own test helpers built on top of unittest (hello, Twisted and Django!) so you don't get to choose anyway. You could write Python code with three-tab indents, but you should use 4-spaces like everybody else. You could write your own custom packaging and dependency management system, but you should use setuptools like everybody else. You could any number of custom test harnesses, but you should use unittest like everybody else.

orf 10y ago
> For one, asserts are removed when you run Python with "-O", so, uh, good luck running your test suite in that configuration Which is not something anyone has ever wanted. > Sure, the unittest module in the standard library is a bit Java-ish, but it's much less magic, and I feel like keeping per-test state in a class that gets instantiated multiple times is more Pythonic than having everything be top-level functions. It's really really unpythonic. It looks horrible and leads to messy tests. With pytest you get dependency injection via fixtures which cuts down on so much repetitive initialisation code. We've got both kinds of tests in our codebase, and the pytest ones are a lot nicer to write and refactor.
- bpicolo 10y ago
  So unpythonic that it even uses camelcase.
- 10y ago