Jmw/use pytest#2
Conversation
|
|
||
| def test_the_whole_song(self): | ||
| expected = """99 bottles of beer on the wall, 99 bottles of beer. | ||
| def test_the_first_verse(): |
There was a problem hiding this comment.
Later in the book we will be putting test suites for different classes in the same file. Is there a way of creating a separate namespace for the tests using Pytest?
There was a problem hiding this comment.
Yes - pytest enables grouping tests via classes and modules (files).
I believe you should be able to group them into the TestClasses to avoid namespace issues.
def test_method_a():
setup_var = 5
object = main.my_class()
actual = object.act(setup_var)
expected = 6
assert actual == expected
def test_method_b():
setup_var = 5
object = main.my_class()
actual = object.send(setup_var)
expected = 6
assert actual == expected
class TestMyClass:
def test_method_a(self):
setup_var = 5
object = main.my_class()
actual = object.act(setup_var)
expected = 6
assert actual == expected
def test_method_b(self):
setup_var = 5
object = main.my_class()
actual = object.send(setup_var)
expected = 6
assert actual == expected
| 'Take one down and pass it around, ' | ||
| '98 bottles of beer on the wall.\n' | ||
| ) | ||
| assert Bottles().verse(99) == expected |
There was a problem hiding this comment.
This looks fine to me, but I don't see why this is better than unittest. They're both equally readable, and one is not more verbose than the other.
Aside from "most people use pytest", is there another compelling reason to choose that over unittest?
There was a problem hiding this comment.
In my experience teaching Python beginners as well as working in our industry, Pytest should be chosen over unittest by default. Outside of academia (not their job to code well) and folks coming from other languages (Java), I haven't seen unittest used. My hunch is it's more of a case of those groups not being aware of pytest to start out with. 🤷♂️
Some high-level items to consider:
- most developers will know Pytest -> easier read for the market audience
- inexperienced readers will have an easier learning curve (eg no need for multiple assert methods)
- After some sleep, I think it unlikely we'll be pulling out
parametrizeor afixturein the book 😆the modern pytest features may come in handy - marks, fixtures, parameterize - despite being written in Python overall, the use of unittest would yet stymie my confidence in recommending this book or leveraging it in future teaching opportunities. 😢
There was a problem hiding this comment.
Remember that this book is explicitly not for Python beginners. It's for Python developers who are new to OOP. We're explicitly not teaching Python.
Outside of academia (not their job to code well) and folks coming from other languages (Java), I haven't seen unittest used
This is probably the best argument, to me. If it's what people expect, then using something else will cause friction. /shrug
It's like using the wrong enumerable method for the job in Ruby.
the modern pytest features may come in handy - marks, fixtures, parameterize
Do you mean that it will come in handy in the context of the book? Can you point out exactly where in the book Pytest will be better than unittest?
no need for multiple assert methods
We only ever use assertEqual in the book.
Despite not seeing the "easier to read" thing myself (they look exactly the same to me) I will switch to using Pytest on the strength of the first argument.
There was a problem hiding this comment.
I don't expect any of these to be used in the book's examples, but in case a brief overview is helpful here are the three features I mentioned. While I don't foresee a use-case, maybe you will 😊 🤷♂️
- fixtures: the streamlined way to provide setup for tests while ensuring clean teardowns when tests complete or fail
- examples: create an infrastructure such as a database or filesystem, provide a Stub/Mock system to avoid I/O calls, or simply do a complex setup for a more hairy test (many required args perhaps)
- parametrize: de-duplicate tests. It's like meta-creating them on the fly, or defining them as a product
- example: instead of writing a test for each possible value of arg, define the possible values and let it make a test for each pair of possibilities
- marks: allow you to group and run tests by a category, separate from the behaviour or module they are defined for.
- examples: tests that are slow-running, require network access, take up large resources, etc
There was a problem hiding this comment.
Thanks. Yeah, I don't see any of this coming up in the context of 99 bottles :)
2 participants
No description provided.