Hello World via Test Driven Development (TDD)
Pick a programming language (maybe the one you primarily use at work)... How hard/simple would it be to execute this kata?
I created a hello world python kata template: Hello World Kata
If you are already familiar with TDD, unit tests, and/or mocking, then this seems like an absurd exercise. Yet, this small program is enough to exercise each rule of TDD plus touch unit testing and mocking. These are the fundamental bases of TDD!
The intention of this article is to define, then walk through one solution to this kata.
Description
Expected Behavior
Create a program, which outputs to the console, 'hello world'.
Constraint
The three rules of TDD as Described by Uncle Bob
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
Solution (Python3)
1: Add test to assert hello_world file exists
Start by creating a test file hello_world_test.py. Assert nothing more than the file exits using an import statement. 1st + 2nd TDD Rule
import hello_world
test fails - ModuleNotFoundError: No module named 'hello_world'
Create hello_world.py as an empty file. 1st + 3rd TDD Rule
# no code, just a new file
test passes
3: Add failing test with mock builtin.print
The Python builtins print is called when the 'print' function is invoked. Update the test to mock this builtin... 2nd TDD Rule
from unittest.mock import patch
@patch('builtins.print')
def test_hello_world(mock_print):
import hello_world
mock_print.assert_called_with('hello world')
test fails : AssertionError: Expected call: print('hello world')
Write the feature code!!!
print('hello world')
test passes
5: Profit! (Done)
Thoughts
Hello world is where a majority of software engineers begin at in any new language. In Python it is simply "print('hello world')".
Yet, one line of feature code is enough to expose the fundamentals of TDD!
Test Driven Development is a programming methodology that takes minutes to learn, but a career to master...
Now most programmers, when they first hear about this technique, think: “This is stupid!” “It’s going to slow me down, it’s a waste of time and effort, It will keep me from thinking, it will keep me from designing, it will just break my flow.” However, think about what would happen if you walked in a room full of people working this way. Pick any random person at any random time. A minute ago, all their code worked.
Top comments (8)
This is too much of an ideal case of programming aka Plato's Cave. After a while, you will skip all of those test commits and go straight to do something more meaningful.
The craftsmanship of the commits in there own right is challenging. I am missing one in which I committed the file creation and the test that does the import at the same time.
Trying to look up how to mock static types or built in is also not trivial.
I learned in this exercise, Python 2 the module is '__builtin__', while Python 3 it is 'builtin'.
Trivial yes, but I see room for improvement AND learned something.
FYI, the concept of deliberate practice... do you think LeBron James still practices free throws, or is that a waste of his time?
expertenough.com/1423/deliberate-p...
Well I don't agree on all of your points:
Trying to look up how to mock static types or built in is also not trivial.: Why do you want to mock a build-in library? Do you not trust that it works?Trivial yes, but I see room for improvement AND learned something.Nothing is trivial up to the point of actually implementing it. Only time will tell if you actually learned something as it's not a one-time endeavor.FYI, the concept of deliberate practice... do you think LeBron James still practices free throws or is that a waste of his time?: I didn't say you wasted your time. It just I believe you will have to practice a more pragmatic approach to testing and committing things.Of course, you have to practice. there is no question about it. But at the end of the day, you have to challenge what exactly do you practice and what realistic goals have you achieved. This is a very fine line between practicing and self-consuming. And in your case, I saw the latter that's why I commented. :@
For mocking built ins, I work on an ETL Integration team, writing unit tests that mock open in Python and read/write IO. At one point this was a pain in the arse.
I love the conversation and don't want to trivialize any concerns you have, FYI :)
I intend to finish/polish this article tonight.
I look at it this like a proof in discrete mathematics. From the base case of what the concept of 1 is, we can prove 1+1=2, then eventually get to calculus or linear algebra.
Ok, I agree with that kind of proofs you need something more formal. Have you explored Coq?
coq.inria.fr/
or Idris
idris-lang.org/
O no, I haven't done formal proofs since college. I was trying to make an analogy.
I have been TDD exclusive for over 4 months (in both professional and personal projects), yet I had not attempted something like this. In the analogy, I had been playing with high level concepts without 'mastering' the base case.
I feel like even in this SIMPLE example, there are a few things that could be better. To get my commits to look pretty, I interactively rebased.
I can't even
Was this a 1/2 finished thought, or are you saying you can't imagine how to even TDD hello world?