I used to use Unittest’s self.assertTrue
/ self.assertFalse
to check both literal
booleans and truthy/falsy values in Unittest. Committed the same sin while writing
tests in Django.
I feel like
assertTrue
andassertFalse
are misnomers. They don’t specifically check literal booleans, only truthy and falsy states respectively.
Consider this example:
# src.py
import unittest
class TestFoo(unittest.TestCase):
def setUp(self):
self.true_literal = True
self.false_literal = False
self.truthy = [True]
self.falsy = []
def is_true(self):
self.assertTrue(self.true_literal, True)
def is_false(self):
self.assertFalse(self.false_literal, True)
def is_truthy(self):
self.assertTrue(self.truthy, True)
def is_falsy(self):
self.assertFalse(self.falsy, True)
if __name__ == "__main__":
unittest.main()
In the above snippet, I’ve used assertTrue
and assertFalse
to check both literal
booleans and truthy/falsy values. However, to test the literal boolean values, assertIs
works better and is more explicit. Here’s how to do the above test properly:
# src.py
import unittest
class TestFoo(unittest.TestCase):
def setUp(self):
self.true_literal = True
self.false_literal = False
self.truthy = [True]
self.falsy = []
def is_true(self):
self.assertIs(self.true_literal, True)
def is_false(self):
self.assertIs(self.false_literal, False)
def is_truthy(self):
self.assertTrue(self.truthy, True)
def is_falsy(self):
self.assertFalse(self.falsy, True)
if __name__ == "__main__":
unittest.main()
Notice how I’ve used self.assertIs
in the is_true
and is_false
methods to explicitly
test out the literal boolean values. The is_truthy
and is_falsy
methods were kept
unchanged from the previous snippet.
Recent posts
- Explicit method overriding with @typing.override
- Quicker startup with module-level __getattr__
- Docker mount revisited
- Topological sort
- Writing a circuit breaker in Go
- Discovering direnv
- Notes on building event-driven systems
- Bash namerefs for dynamic variable referencing
- Behind the blog
- Shell redirection syntax soup