Test-First Smalltalk Programming With The Debugger

I found a good introduction to test-first programming with the debugger in Smalltalk, from Pharo by Example (6.5 The Debugger):

The evaluation of the expression 'readme.txt' suffix will complete, and print the answer '.txt'.

Is the answer correct? Unfortunately, we can’t say for sure. Should the suffix be .txt or txt? The method comment in suffix is not very precise. The way to avoid this sort of problem is to write an SUnit test that defines the answer.

Method 6.2: A simple test for the suffix method:

StringTest >> testSuffixFound
    self assert: 'readme.txt' suffix = 'txt'

The effort required to do that was little more than to run the same test in the workspace, but using SUnit saves the test as executable documentation, and makes it easy for others to run. Moreover, if you add method 6.2 to the class StringTest and run that test suite with SUnit, you can very quickly get back to debugging the error. SUnit opens the debugger on the failing assertion, but you need only go back down the stack one frame, Restart the test and go Into the suffix method, and you can correct the error, as we are doing in Figure 6.32. It is then only a second of work to click on the Run Failures button in the SUnit Test Runner, and confirm that the test now passes.

Here is a better test:

Method 6.3: A better test for the suffix method

StringTest >> testSuffixFound
    self assert: 'readme.txt' suffix = 'txt'.
    self assert: 'readme.me.txt' suffix = 'txt'

Why is this test better? Because it tells the reader what the method should do if there is more than one dot in the target String.