Sponsored repty to Vasilina and Nazar
General sequence for anything in Test Driving Development
- Try and Fail
- Fix and Confirm
- Polish
- Repeat
Also knows as:
Red - Green - Refactoring - Repeat
(Red/Green refer to test frameworks colored output)
So lets try and fail first
We start with nothing: no tests, no code. Just empty project folder.
Let’s run tests. What we expect from running tests in empty folder?
We expect message that there are zero tests and there is nothing to run. If we get this message - that count as success.
Let’s try:
$ pytest
And the output is:
pytest: No such file or directory
We are at RED state here, we tried and failed.
Let’s fix that and get GREEN state
Install pytest:
$ pip install pytest
Output:
Installing collected packages: pytest
Successfully installed pytest-7.2.0
Confirm green state
Now, lets run tests again
$ pytest
And now we get
$ pytest
============================== test session starts ==============================
platform linux -- Python 3.10.1, pytest-7.2.0, pluggy-1.0.0
rootdir: /home/snowyurik/tmp/10
asyncio: mode=strict
collected 0 items
============================= no tests ran in 0.00s =============================
Polish
Let’s look into our code: do we have any Code Smells?
(“code smells” or “antipatterns” are rules to detect bad code, most notable are “duplicated code” and “magic” aka “hardcode”)
No code = no code smells, excellent!
Refactoring is done 😎
Repeat
To start next iteration we have to change our expectations.
Let’s expect now, that we run at least one test
Try and fail
Btw, I advice you to really do so and I’m actually doing such “pointless” actions on everyday basis.
$ pytest
And we get
$ pytest
============================== test session starts ==============================
platform linux -- Python 3.10.1, pytest-7.2.0, pluggy-1.0.0
rootdir: /home/snowyurik/tmp/10
collected 0 items
============================= no tests ran in 0.00s =============================
Same message, but as for as our expectation changed, we can’t be satisfied with it anymore.
From now we will interpret no tests ran in 0.00s as RED state.
Let’s fix that and confirm the fix 😊
Add simplest possible test.
Here are some official docs https://docs.pytest.org/en/7.2.x/getting-started.html but who have time to read everything?
That will be just empty file, test.py (by the way, that’s not correct name)
$ touch test.py
Does it work?
$ pytest
============================== test session starts ==============================
..
collected 0 items
============================= no tests ran in 0.00s =============================
No
Why?
Let’s have a quick look at the docs… maybe our test file was not found automatically, so lets rename it exactly like in example:
mv test.py test_sample.py
Run pytest again, does it work now? No. So we need more, let’s copy-paste code from tutorial, this will be our test_sample.py content
# content of test_sample.py
def func(x):
return x + 1
def test_answer():
assert func(3) == 5
What does this code mean? We don’t care
Right now all we want is to get message from pytest that at least one test was executed, no more, no less.
$ pytest
============================= test session starts ==============================
...
collected 1 item
test_sample.py F [100%]
=================================== FAILURES ===================================
_________________________________ test_answer __________________________________
def test_answer():
> assert func(3) == 5
E assert 4 == 5
E + where 4 = func(3)
test_sample.py:7: AssertionError
=========================== short test summary info ============================
FAILED test_sample.py::test_answer - assert 4 == 5
============================== 1 failed in 0.05s ===============================
Success!
Yep, it’s colored red, but we see that tests are executed.
And pytest shows us where exactly test failed.
Let’s polish that and make our green state actually green
Here is our test
def test_answer():
assert func(3) == 5
What’s going on here?
Pytest (by the way, unittest for python act the same) will find functions which started with test_ and execute them.
Ok, what is assert?
assert equals “we excepect that the following statement is true”. So assert func(3) == 5 mean “we expect that func(3) will return 5”.
But it does not. So lets modify func()
def func(x):
return x + 2
And run pytest again
$ pytest
============================== test session starts ==============================
...
collected 1 item
test_sample.py . [100%]
=============================== 1 passed in 0.01s ==============================
Now our green state is actually green, nice 🙂
Lets see if we have some code smells here and mark them with /// TODO
def func(x): /// TODO function name does not describe function
return x + 2 /// TODO hardcoded value 2
def test_answer():
assert func(3) == 5 /// TODO hardcoded values 3 and 5
We can’t leave it like that. Why do we have this code at first place? We just copied example. It make no sense in our project and it should not.
What are we testing at first place?
We are testing ability to run tests. Let’s modify the test so it will server only intendent purpose:
We do not need def func(x) at all, so we remove that and run pytest again:
E NameError: name 'func' is not defined
Hmm.. let’s replace func(3) with it’s result:
def test_answer():
assert 5 == 5
Green state. But we still have hardcoded 5. Lets just use True:
def test_answer():
assert True
And make test name self-explanatory
def test_ifWeCanExecuteTests():
assert True
Run pytest. State is green. What else we have? Oh yes, filename. As you remember, test.py did not work, but was it filename issue or it was lack of test functions inside? We can check:
$ mv test_sample.py test.py
$ pytest
...
============================= no tests ran in 0.00s =============================
Looks like filename should be like test<undescore><something>.py. Let’s try and make is self-explanatory
$ mv test.py test_application.py
$ pytest
... [100%]
=============================== 1 passed in 0.00s ===============================
Refactoring done 🙄
Repeat 😅
Now we are ready to implement something real. For that we need the task.
Let it be:
“Create validator for phone number”\
Try and fail
We start from wring another test before any implementation
def test_validatePhome():
assert isValid("+1(111)11-11-111")
And run test
E NameError: name 'isValid' is not defined
We are at RED state.
Fix and confirm
Now our goal is to achieve GREEN state in the simplest possible way.
def isValid():
return True
def test_validatePhome():
assert isValid("+1(111)11-11-111")
Now it’s green.
Refactor
Yep, we can do that, but let’s assume we are lazy and see if TDD will force use to do that.
Repeat
Let’s add another test, we need RED state, remember.
Try and fail
def test_validatePhome():
assert isValid("+1(111)11-11-111")
assert isValid("+2(222)22-22-222")
Pytest and.. still green. We need red. ANY new test make no sence. As for we need red we have to write test which will fail.
How about that one
def test_validatePhome():
assert isValid("+1(111)11-11-111")
assert isValid("this is definitely not valid phone number") == False
Pytest:
FAILED test_application.py::test_validatePhome - AssertionError: assert True == False
Nice, RED state
Fix and confirm
Why second “phone number” is not correct? There are many answers. Let’s say it’s too long. Looks like valid phone numbers can contain maximum 15 digits.
So let’s check that inside isValid
def isValid(phone):
if( len(phone) > 15 ):
return False
return True
And.. our first asserting failed. Because len("+1(111)11-11-111") is actually 16. So we see that we can’t just count symbols. We need to count digits.
def isValid(phone):
digits = sum(symbol.isdigit() for symbol in phone)
if( digits > 15 ):
return False
return True
Does it work? First assertion is passed, but “this is definitely not valid phone number” actually has zero digits. Which is also not correct, so:
def isValid(phone):
digits = sum(symbol.isdigit() for symbol in phone)
if( digits > 15 or digits < 6 ): // 6 is minimal
return False
return True
And now its green 🤗
Polish
Obviously 15 and 6 are “magic numbers” aka “hardcode”. We can turm them into constants with self-explanatory names:
And also move them to separate file together with isValid function, because it’s a mess now. Let’s say phoneValidator.py
MIN_PHONE_NUMBER_LENGTH = 6
MAX_PHONE_NUMBER_LENGTH = 15
def isValid(phone):
digits = sum(symbol.isdigit() for symbol in phone)
if( digits > MAX_PHONE_NUMBER_LENGTH or digits < MIN_PHONE_NUMBER_LENGTH ):
return False
return True
And for our test to work we need import it, so:
from phoneValidator import *
def test_ifWeCanExecuteTests():
assert True
def test_validatePhome():
assert isValid("+1(111)11-11-111")
assert isValid("this is definitely not valid phone number") == False
Pytest.. green 🥳
Continue like that
Can you imagine another wrong phone number which will pass the test? Create the test and change implementation.
No? Can you imagine correct phone number which won’t pass the test? Crete the test for false-negative result and change implementation.
With iterative process like that, you will get closer and closer to ideal solution.
Can you do it faster on-sight? Maybe. If you are good at regular expressions and phone standarts you might not need tests.
But to create something with test you do not have to be good at anything including test themselfves!
Just keep it simple, keep it iterative, do small steps, always refactor old code and you will create anything. There is no limit.