Maxcode123/unittest-extensionsPublic

NotificationsYou must be signed in to change notification settings
Fork0
Star3

Extension of Python's standard unittest library

maxcode123.github.io/unittest-extensions/

License

MIT license

3 stars 0 forks Branches Tags Activity

Star

Notifications

You must be signed in to change notification settings

Branches Tags

Folders and files

Name		Name	Last commit message	Last commit date
Latest commit History 59 Commits
.github/workflows		.github/workflows
docs		docs
src/unittest_extensions		src/unittest_extensions
.gitignore		.gitignore
LICENSE		LICENSE
Makefile		Makefile
README.md		README.md
mkdocs.yml		mkdocs.yml
pyproject.toml		pyproject.toml

Repository files navigation

Documentation:https://maxcode123.github.io/unittest-extensions/
Source code:https://github.com/Maxcode123/unittest-extensions
PyPI:https://pypi.org/project/unittest-extensions/

unittest-extensions

Extension of Python's standard unittest library

Introduction

If testing is not easy, you will not do it.
If you do not test, bad things will happen.
Thus, if testing is not easy, bad things will happen.

This minimal library aims to simplify behavioural testing with Python's standardunittest library by separatingobject and data creation from behaviour assertion. Furthermore, it is intended to serve users that want to write really small test functions where what is being asserted is quickly comprehended and easily visible.

unittest-extensions does not have any dependencies, it is solely based on thePython standard library and mainly inspired by Ruby'sRSpec framework.

Installation

pip install unittest-extensions

Usage

Suppose you have some code that looks like this:

fromdataclassesimportdataclass@dataclassclassUser:name:strsurname:strdefis_relative_to(self,user:"User")->bool:returnself.surname.casefold()==user.surname.casefold()

This is a dummy example, meaning that how exactly the User and their methods are implemented does not really matter; what we actually care about here is how to test this code given the above implementation.
Say we'd like to test theis_relative_to method with pairs of User names and surnames using the standardunittest library.So, here's an example of how we could do that as simply as possible:

std unittest

fromunittestimportmain,TestCaseclassTestIsRelativeToSameName(TestCase):deftest_same_name(self):user1=User("Niklas","Strindberg")user2=User("Niklas","Ibsen")self.assertFalse(user1.is_relative_to(user2))deftest_same_empty_name(self):user1=User("","Stringberg")user2=User("","Ibsen")self.assertFalse(user1.is_relative_to(user2))classTestIsRelativeToSameSurname(TestCase):deftest_same_surname(self):user1=User("August","Nietzsche")user2=User("Henrik","Nietzsche")self.assertTrue(user1.is_relative_to(user2))deftest_same_empty_surname(self):user1=User("August","")user2=User("Henrik","")self.assertTrue(user1.is_relative_to(user2))deftest_same_surname_case_sensitive(self):user1=User("August","NiEtZsChE")user2=User("Henrik","nietzsche")self.assertTrue(user1.is_relative_to(user2))deftest_surname1_contains_surname2(self):user1=User("August","Solzenietzsche")user2=User("Henrik","Nietzsche")self.assertFalse(user1.is_relative_to(user2))if__name__=="__main__":main()

The cases we check here are rather limited but still there is some duplication in our code; we use many lines to create our User subjects. Of course we can avoid thatby creating custom assertion methods that receive only the parameters that changebetween tests, but that's why a testing library is here for.
Here's how we could write the above code withunittest-extensions: