As many people pointed at already, the British summer has started.
Expect a season of rain with spells of sun from time to time to prevent boredom for the part of the population who is not undergoing the summer migration to the Mediterranean.
On the up side it gives nice opportunities to do interesting photograph like this beautiful shot of Trafalgar Square posted in the West London flickr group.
It’s the first time I come across this catalog of testing pitfalls.
It’s amazing, as I can associate almost all of them to my own errors or to other’s work.
It’s very useful to put a descriptive semi-humourous name for each of these as facilitate their teaching and our ability to remember them.
This link will definitely find its way in my team’s developments standards and guidelines.
“Somehow I missed James Carr’s TDD Anti-Patterns late last year. I’ve perpetuated almost every one at least once. If you’re new to testing, browse the list, think about each entry, and watch for it in your own code.”
(Via ONLamp.com.)
What electric ambience here in this gorgeous festival of light. It looks like the cockpit of an x-fighter jumping into hyper-space!
I also like the details in the rear-view mirrors.
Very cool shot.
I use vim as my text editor.
Practicing TDD for creating perl applications usually imply the following workflow:
the perl code (*.pm) and the test code (*.t) open in the same terminal view where the vim window is split into two horizontal halves. That’s on my left display.
On the right display is a shell where I do run the test (prove my_test.t and its variations). The right display is also used for perldoc (and the web browser).
On the left display I obviously switch often between the two halves, writing some tests then writing the code, going back to the test code to write some more. Between each switch I always run the test.
Because of the convenience of having the test code and the application code on the same window, the ease of switching with vim and the rhythm of TDD I found TAB-switching to the other terminal window on the other screen counter productive.
I know that some people run a !prove mytest.t in command mode under vim, but that’s still too long and you have to type the name of the file.
Granted you do that only once and the other times you can just type !! to re-exec the last command.
This is screwed, if you do run other commands in the same way as the last command may not be the one you think it is anymore.
vim as a built-in command make that does different things depending on the mode. The usual set up for perl is for make to do syntax checking (perl -Wc) on the current file. This can be setup in the vim configuration file (.vimrc) in a user home directory (on UNIX) using the makeprg option.
If make could run the test for me instead of syntax checking that would be a better solution than what I described above. However I don’t want to loose the ability to syntax check as it is faster and less confusing to find stupid typos that way rather than seeing a test failing and trying to find the reason amidst the jungle of error messages.
Also, ideally, I’d like to syntax check and test run to be triggered by a press of a key rather than having to type :make.
So I’ve added these lines in my .vimrc:
map <F4> :w<cr>:set makeprg=perl\ -c\ %<cr>:make<cr> map <F8> :w<cr>:set makeprg=prove\ -v\ %<cr>:make<cr>
After switching to the test code, pressing F8 will run the test while pressing F4 will do a syntax check.
F4 will work on any perl script, so you can syntax check both the application code and the test code.
Also you don’t have to save the file as the file will be saved before syntax check or tests is run.
You have to switch to the test code before you can press F8 to run the test.
Pressing F8 when the application code is the current file will attempt to run prove on it which will fails of course.
Ideally, in this situation, I’d like vim to find and run the corresponding test based on location/name of the application code but I don’t know how to do that.
The fact that all the main activities I do are now done on one split window, leaves the second screen for documentation (perldoc and web browser), running the whole test suite, doing other tasks, …
The benefit of the split window is also very useful when doing TDD in a Coding Dojo (or if you have only one screen) as there’s only one screen projected on a wall for the audience to see and everything is happening on this screen.
