Published: September 11, 2020
Testing can be a pain. It is painful to write test cases. Without it, doing manual testing sucks the life out of you. This makes it worst when you had to remember every single command and steps that could take hours to do it.
I know the importance of delivery when you are on a time crunch & death march to get it done. But... if your spending tons of effort to test your deployment. You are sabotaging yourself as these could be automated. Which frees up your time to make changes to your code to make it better, faster and maintainable for your future self or teammates who will be maintaining it.
This is the default testing framework that comes with Python whenever you install Python in your development environment. I won't be introducing alot of it. As you learn about Java, it draws inspiration from JUnit.
I found that one big grumble that I had with the default framework that is bundled with Python. It is boilerplate code when you are creating test cases. Look at this example of a test case which is enough for me to stop learning it. Due to the amount of boilerplate code to write it to test my code:
import unittest class TestStringMethods(unittest.TestCase): def test_upper(self): self.assertEqual('foo'.upper(), 'FOO') def test_isupper(self): self.assertTrue('FOO'.isupper()) self.assertFalse('Foo'.isupper()) def test_split(self): s = 'hello world' self.assertEqual(s.split(), ['hello', 'world']) # check that s.split fails when the separator is not a string with self.assertRaises(TypeError): s.split(2) if __name__ == '__main__': unittest.main()
Pytest is still my goto testing framework. What I love about Pytest. It is the ease to get started with it and without tons of boilerplate to make it work.:
# From the previous example of the unit test but in Pytest def test_upper(): assert 'foo'.upper() == "FOO" def test_isupper(): assert 'FOO'.isupper() == True assert 'Foo'.isupper() == False def test_split(): s = 'hello world' assert s.split == ['hello', 'world'] assert type(s.split(2)) == str
This allows you to create smoke test to get a rough understanding of your program. Not forgetting PyCharm Professional edition makes it easy to automate and do Test Driven Development (TDD). Which is part of the reason that I would still stay with PyCharm due to the number of things I like about them.
But in layman terms, it is framing your test cases into user stories using the Given-When-Then~tags~(~'given20when20then))~searchTerm~'~sort~false~sortDirection~'asc~page~1)) formula. This allows ease of understanding for the context in your test cases for anyone be it a designer, product owner or a developer. As your frame your user stories into test cases using that formula.
Currently, I do not need it for my work. But I gained more insights, when I was reading The Pragmatic Programmer. Which gave me the perspective to combined it with TDD practices to form a dragnet.
To test out various scenarios as a test case. Which once a bug has been found. You patch your program and create a unit test to catch the bug from ever occurring again in the future.
I had outlined the need for writing test cases to automate the testing process so that it frees you to focus on higher-value work. Like writing documentation, improving your CI/CD pipeline or even pair programming with your junior developer to speed up their learning process.
I had also covered the 3 python testing frameworks. That I know namely unittest that comes with Python. PyTest which is one of my favourite testing frameworks. behave that focus on the use of BDD to create test scenarios from user stories using the Give When Then formula.
Lastly, are you looking to specialise yourself as a developer? If it's a Yes. I'm giving away my free ebook called "Picking Your Specialisation as a Developer" for anyone interested to command a higher salary or do the work that you like.
This post includes affiliate links, I may receive compensation if you purchase products or services from the different links provided in this article.