I am stuck at step 3 for ex48. I have gotten the test to run without error or displaying the input, and I have gotten it to run with a pass on any input (having filled in a basic lexicon.py). However, I can’t figure out how to make it fail. Maybe I do not understand what “Write the first line of the test_directions test case” means?
If you’re at #3 “Write the first line of the test_directions test case. Make it fail.”
then your lexicon_tests.py should only have:
from nose.tools import *
from ex48 import lexicon
def test_directions():
assert_equal(lexicon.scan('north'), [('direction', 'north')])
Inside lexicon.py, you should not yet have a scan function. Now run nosetest. This should “Make it fail.”
On step #4, now create an empty scan function:
def scan():
return
Then step #5, run nosetest “even though it fails”.
Then step #6.
All the way through ex48, you add an assert_equal, run nosetest and see that it fails. Then add code to the scan function to make the assert_equal true and run nosetest.
Add another assert_equal, run nosetest, see that it fails. Then add code to the scan function to make it true.
Repeat.
Oh, I understand now. I thought the program was supposed to throw an error when run as python tests/ex48_tests.py. This was what ran without error.
Yes, the nosetest does fail when I run it on my posted code. It is good to know that “failing” code means code that fails a nosetest, not code that throws an error when run.
The “make it fail” is really the basis of ‘red, green, refactor’ or Test-Driven Development. It can be advantageous to get into the habit of write small tests for things you have not yet developed, and then use the tests to drive your development process, implementing each, one by one.
The test results update from red (failing) to green (passing) which then gives you a quality safety net when you tidy up the code later (refactoring).
This is one of the reasons I use PyTest over Nose as the Terminal colours lets you know results at a glance, which is helpful when flipping between test results and code quickly.
It’s also important to see the change in state in test cases as it’s very easy to write an incorrect test that always passes, but doesn’t actually exercise the code as intended. Or as I did in this post point the test in the wrong area so missed the error.