Comments on: TDD: The ‘Logans Run’ of Software Development… http://cyberfox.com/blog/2007/10/05/35/tdd-the-logans-run-of-software-development Coding, Connections, and Other Bloggy Bits of Goodness Fri, 08 Jan 2010 09:11:39 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Cyberfox http://cyberfox.com/blog/2007/10/05/35/tdd-the-logans-run-of-software-development/comment-page-1#comment-4900 Cyberfox Fri, 22 May 2009 02:31:49 +0000 http://www.vixen.com/blog/2007/10/05/35#comment-4900 Greetings, I evidently need to tweak my WordPress setup; I didn't know this old post even had new comments on it. :( I like the idea of segregating tests; so when doing specific fixes (i.e. maintenance), you don't even try to run your whole unit test suite until you feel you're done and integrating. There should be a way to do that easily... Many of you suggested Michael Feathers book on legacy code. I recall skimming it in a store well before I ever wrote that post (which was back in late 2007), and for some reason I've mentally binned it with 'Code Reading' by Diomidis Spinellis which I thought was a singularly poor treatment of the subject. I may need to re-examine 'Working Effectively', and see if I merely confused the two, or if I had a legitimate disagreement with it. I've since been through Yet Another company who had extremely poorly tested code (in fact, zero tests or specs when I came on board; outsourced code FAIL), and it definitely frustrates me. I'll have to see if there's a way to tune autotest to switch into a 'legacy fixes' mode, which only runs a single test suite as you're making changes. Anyhow, I appreciate the comments. There's some good ideas, and the impetus to take a second look at Michael Feathers' book. -- Morgan Greetings,

I evidently need to tweak my WordPress setup; I didn’t know this old post even had new comments on it. :(

I like the idea of segregating tests; so when doing specific fixes (i.e. maintenance), you don’t even try to run your whole unit test suite until you feel you’re done and integrating. There should be a way to do that easily…

Many of you suggested Michael Feathers book on legacy code. I recall skimming it in a store well before I ever wrote that post (which was back in late 2007), and for some reason I’ve mentally binned it with ‘Code Reading’ by Diomidis Spinellis which I thought was a singularly poor treatment of the subject. I may need to re-examine ‘Working Effectively’, and see if I merely confused the two, or if I had a legitimate disagreement with it.

I’ve since been through Yet Another company who had extremely poorly tested code (in fact, zero tests or specs when I came on board; outsourced code FAIL), and it definitely frustrates me. I’ll have to see if there’s a way to tune autotest to switch into a ‘legacy fixes’ mode, which only runs a single test suite as you’re making changes.

Anyhow, I appreciate the comments. There’s some good ideas, and the impetus to take a second look at Michael Feathers’ book.

– Morgan

]]> By: Carl http://cyberfox.com/blog/2007/10/05/35/tdd-the-logans-run-of-software-development/comment-page-1#comment-4860 Carl Mon, 11 May 2009 15:27:56 +0000 http://www.vixen.com/blog/2007/10/05/35#comment-4860 Michael Feathers wrote the book "working effectively with legacy code" on exactly this area. It's well worth looking at. Not exclusively Java either... Michael Feathers wrote the book “working effectively with legacy code” on exactly this area. It’s well worth looking at. Not exclusively Java either…

]]> By: Ian Mayo http://cyberfox.com/blog/2007/10/05/35/tdd-the-logans-run-of-software-development/comment-page-1#comment-4854 Ian Mayo Sat, 09 May 2009 05:01:02 +0000 http://www.vixen.com/blog/2007/10/05/35#comment-4854 Hi there Morgan, from memory the intended role of TDD in the maintenance of legacy codebases is as a refactoring safety belt. So, before you make 'risky' changes to a portion of legacy code, write some white-box tests to verify the outputs of that module - here you're encoding an API reference for that module. Then hack away with your machete to tidy/refactor it. Then re-run the tests to verify that: a) your expectations of that module were correct b) you haven't changed the outside appearance of that module (or that any changes you made were intentional). The tests then serve as verified, auto-updating API documentation for that module. Yes, it's easier to preach this than to practice it. Yes, I could adhere to it more than I do. Ian Hi there Morgan,
from memory the intended role of TDD in the maintenance of legacy codebases is as a refactoring safety belt.

So, before you make ‘risky’ changes to a portion of legacy code, write some white-box tests to verify the outputs of that module – here you’re encoding an API reference for that module. Then hack away with your machete to tidy/refactor it. Then re-run the tests to verify that:
a) your expectations of that module were correct
b) you haven’t changed the outside appearance of that module (or that any changes you made were intentional).

The tests then serve as verified, auto-updating API documentation for that module.

Yes, it’s easier to preach this than to practice it. Yes, I could adhere to it more than I do.

Ian

]]> By: John Bender http://cyberfox.com/blog/2007/10/05/35/tdd-the-logans-run-of-software-development/comment-page-1#comment-4850 John Bender Fri, 08 May 2009 14:43:14 +0000 http://www.vixen.com/blog/2007/10/05/35#comment-4850 Cucumber provides the tags for focusing on certain tests: http://railscasts.com/episodes/159-more-on-cucumber Cucumber provides the tags for focusing on certain tests:

http://railscasts.com/episodes/159-more-on-cucumber

]]> By: orangepips http://cyberfox.com/blog/2007/10/05/35/tdd-the-logans-run-of-software-development/comment-page-1#comment-4849 orangepips Fri, 08 May 2009 14:01:45 +0000 http://www.vixen.com/blog/2007/10/05/35#comment-4849 Read "Working Effectively with Legacy Code" by Michael C. Feathers. This book provides heuristics and strategies that focus on writing tests around what's being changed. It does not advocate writing unit tests for the whole system before making changes, but rather writing tests around the areas that are being changed. Such that you write tests to capture how the area that's going to be changed behaves. Note, this may involve making changes to that code to make it testable, which the book provides ideas on how to approach. Then make changes and unit test. Read “Working Effectively with Legacy Code” by Michael C. Feathers. This book provides heuristics and strategies that focus on writing tests around what’s being changed. It does not advocate writing unit tests for the whole system before making changes, but rather writing tests around the areas that are being changed. Such that you write tests to capture how the area that’s going to be changed behaves. Note, this may involve making changes to that code to make it testable, which the book provides ideas on how to approach. Then make changes and unit test.

]]> By: Hamlet D'Arcy http://cyberfox.com/blog/2007/10/05/35/tdd-the-logans-run-of-software-development/comment-page-1#comment-4848 Hamlet D'Arcy Fri, 08 May 2009 12:04:01 +0000 http://www.vixen.com/blog/2007/10/05/35#comment-4848 You, sir, need to read Michael Feather's "Working Effectively with Legacy Code". The book was published in 2004, so it's something the Agile folks have been grappling with for at least 5 years. There was a rousing session at CITCON North America on the subject two weeks ago, but alas you weren't there! You, sir, need to read Michael Feather’s “Working Effectively with Legacy Code”. The book was published in 2004, so it’s something the Agile folks have been grappling with for at least 5 years. There was a rousing session at CITCON North America on the subject two weeks ago, but alas you weren’t there!

]]> By: Keith Braithwaite http://cyberfox.com/blog/2007/10/05/35/tdd-the-logans-run-of-software-development/comment-page-1#comment-4845 Keith Braithwaite Fri, 08 May 2009 06:48:52 +0000 http://www.vixen.com/blog/2007/10/05/35#comment-4845 Leading TDD-er Michael Feathers has published a comprehensive and authoritative work on the topic: "Working Effectively with Legacy Code" http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052/ Leading TDD-er Michael Feathers has published a comprehensive and authoritative work on the topic: “Working Effectively with Legacy Code” http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052/

]]> By: Mike http://cyberfox.com/blog/2007/10/05/35/tdd-the-logans-run-of-software-development/comment-page-1#comment-4842 Mike Fri, 08 May 2009 01:15:43 +0000 http://www.vixen.com/blog/2007/10/05/35#comment-4842 I think TDD proponents would tell you that one of the best ways to introduce tdd, or automated testing at all, on an existing project is to try to write tests for every bug-fix that you do, or every new enhancement that you have to make. Bug 1003323849 comes in. Write a test, somehow, that fails for what's in the bug. Fix the bug. Make sure the test passes. It's not always easy to work an automated test into the guts of an existing application, but if you make the effort to do so then soon you'll have a pretty big set of tests that test against known issues instead of lots of "theoretical" bugs that haven't happened. I think TDD proponents would tell you that one of the best ways to introduce tdd, or automated testing at all, on an existing project is to try to write tests for every bug-fix that you do, or every new enhancement that you have to make.

Bug 1003323849 comes in. Write a test, somehow, that fails for what’s in the bug. Fix the bug. Make sure the test passes.

It’s not always easy to work an automated test into the guts of an existing application, but if you make the effort to do so then soon you’ll have a pretty big set of tests that test against known issues instead of lots of “theoretical” bugs that haven’t happened.

]]> By: Giles Bowkett http://cyberfox.com/blog/2007/10/05/35/tdd-the-logans-run-of-software-development/comment-page-1#comment-4841 Giles Bowkett Fri, 08 May 2009 01:10:25 +0000 http://www.vixen.com/blog/2007/10/05/35#comment-4841 I've seen this too, and I'm not sure what the answer is. However, I have to tell you, working on legacy apps that don't have test coverage is a heinous pain in the ass - things break and you have no idea why. What I usually do is just isolate my tests in a separate file. I used a blog post about it as my site, so you should be able to click my name and see it. Basically you just throw the test in one file which only tests for the things you need. The Achilles heel for that approach is complicated objects that require shit-tons of association classes to exist before they can do anything. It kicks ass for many use cases, though. There's a lot you can do to stay TDD this way, and fast as hell, and it's usually very easy to move the tests from their unique files into the larger existing test files. And sometimes it's better to have separate files anyway, because you've got your tests separated by topic and not just by the class they test. I’ve seen this too, and I’m not sure what the answer is. However, I have to tell you, working on legacy apps that don’t have test coverage is a heinous pain in the ass – things break and you have no idea why. What I usually do is just isolate my tests in a separate file. I used a blog post about it as my site, so you should be able to click my name and see it. Basically you just throw the test in one file which only tests for the things you need. The Achilles heel for that approach is complicated objects that require shit-tons of association classes to exist before they can do anything. It kicks ass for many use cases, though. There’s a lot you can do to stay TDD this way, and fast as hell, and it’s usually very easy to move the tests from their unique files into the larger existing test files. And sometimes it’s better to have separate files anyway, because you’ve got your tests separated by topic and not just by the class they test.

]]> By: Cyberfox http://cyberfox.com/blog/2007/10/05/35/tdd-the-logans-run-of-software-development/comment-page-1#comment-3751 Cyberfox Fri, 02 Nov 2007 08:57:09 +0000 http://www.vixen.com/blog/2007/10/05/35#comment-3751 Greetings, Yeah, I'm using rcov as much as I can (had to hack up custom rcov scripts to get it to work), trying to use Heckle but having some issues... Using flog to find bad code sections... I don't know what 'shoulda' is, I'll look it up. It's not so much my clients, but my company, as I've never done the contract thing. I wish I could carve out time explicitly, but instead I have to pad my estimates and use the extra time to improve the test coverage, and do my best to encourage a testing culture in the other devs so we don't fall too far behind. :) I've been given a lot of freedom to do deep refactorings that both improve the ability to build future features, _and_ provides points that can be mocked to improve testability. But doing TDD at this point in the development cycle is just painful, unfortunately. I get my TDD fix working on my own projects. :) -- Morgan Greetings,
Yeah, I’m using rcov as much as I can (had to hack up custom rcov scripts to get it to work), trying to use Heckle but having some issues… Using flog to find bad code sections… I don’t know what ’shoulda’ is, I’ll look it up.

It’s not so much my clients, but my company, as I’ve never done the contract thing. I wish I could carve out time explicitly, but instead I have to pad my estimates and use the extra time to improve the test coverage, and do my best to encourage a testing culture in the other devs so we don’t fall too far behind. :)

I’ve been given a lot of freedom to do deep refactorings that both improve the ability to build future features, _and_ provides points that can be mocked to improve testability.

But doing TDD at this point in the development cycle is just painful, unfortunately. I get my TDD fix working on my own projects. :)

– Morgan

]]>