Coding kata starter in Python
This is how I usually start a coding kata, here in Python. It should be easy and very fast, so I can move on to the kata (the interesting part).
Rationale: some kata repositories provide a starter in many languages. If this works for you this is great, you might not need this article. This article is intended to people that want to quickly start from scratch (because I find it to be rather easy), and / or people that have found that this or that repository does not use your version of the runtime, or uses old versions of testing libraries, or does not use your favorite libraries, or are even slower than starting from scratch.
So here is what I use. It should take less that 3 mn (you can practice to go even faster than that), and give you a shareable public repository ready to write tests and have a linter ready for fast feedback. Now we can move on to the kata.
If you find that useful, you can go further and adapt it to your prefered testing lib or your prefered language.
Prerequisite: have a Python 3 runtime available. Usually this also provides virtualenv. If not: `sudo apt install virtualenv`.
Let's suppose we have chosen to practice with the famous Bowling kata.
Project start:
$ mkdir bowling-kata $ cd bowling-kata
Create a virtualenv, activate it (⚠️ shell dependent ⚠️) and install pytest.
$ virtualenv -p python3 venv $ source venv/bin/activate $ pip install pytest
Note: if you know & prefer the unittest module from the Python standard lib, you don't even need this virtualenv & pytest installation step.
Write the shortest possible failing test in your favorite editor in "bowling_test.py", for example:
def test_fails():
assert 0 == 1
Run the test, it should fail with the correct error message:
$ pytest
============================== test session starts ===============================
platform linux -- Python 3.10.6, pytest-7.4.0, pluggy-1.2.0
rootdir: /home/sebastien/Developer/scratch/bowling-kata
configfile: pytest.ini
collected 1 item
bowling_test.py F [100%]
==================================== FAILURES ====================================
___________________________________ test_fails ___________________________________
def test_fails():
> assert 0 == 1
E assert 0 == 1
bowling_test.py:2: AssertionError
============================ short test summary info =============================
FAILED bowling_test.py::test_fails - assert 0 == 1
=============================== 1 failed in 0.01s ================================
For a learning session, you should be good to go. This is where I usually stop the setup part and start working on the kata. Your IDE should catch most lint errors already. Optional: `pip install flake8` if needed.
(Optional) Create a more elaborate directory structure
$ mkdir src $ mkdir test $ mv bowling_test.py test
Add a bowling function in `src/bowling.py`:
def bowling():
return 1
Import it from `test/bowling_test.py`:
from bowling import bowling
def test_fails():
assert 0 == bowling()
Add `src` to pytest’s pythonpath in `pytest.ini`:
[pytest] pythonpath=src
Running `pytest` again should give you the same correct error message.
The final structure:
$ tree -I __pycache__/ -I venv -I .pytest_cache/
.
├── pytest.ini
├── src
│ └── bowling.py
└── test
└── bowling_test.py
(Optional) Git setup
This is useful in remote contexts if you want to take turns in the session.
$ echo venv >> .gitignore $ echo __pycache__ >> .gitignore $ echo .pytest_cache >> .gitignore $ git init $ git add . $ git commit -m first
Create a new repo on github or gitlab or ..., then copy / paste the github provided snippet to setup the remote and push.
Kata Animation tips
Always leave the test code, implementation code, and test logs visible at all times. Use split windows, your IDE or tmux can help with that. This allows everyone to have time to finish reading the code or the error messages at all times.
Explicitely state that the primary goal is to have a shared understanding, not to finish the kata at all cost.
Finish the session 10 mn early, use this time for a debrief. Listen to what everyone wants to share about this particular session.
For a live coding session, learning to type code fast can help keeping the session dynamic, and frees some time for the conversation. If the keyboard changes hands, don't blame someone for typing slowly.