Tips for Testable code and for testing legacy code

My blog has moved. You can view this post at the following address: http://www.osherove.com/blog/2007/6/10/tips-for-testable-code-and-for-testing-legacy-code.html
Published Sunday, June 10, 2007 4:09 PM by RoyOsherove
Filed under: , , , ,

Comments

Sunday, June 10, 2007 6:04 PM by Ayende @ Rahien

# Dealing with legacy code

Dealing with legacy code

Friday, June 15, 2007 12:44 AM by thiagodp

# re: Tips for Testable code and for testing legacy code

"If possible, create an interface per class. You never know when you're gonna need it." I think the YAGNI (You Aren't Gonna Need It) principle can be "cheaper", in most of cases: "Always implement things when you actually need them, never when you just foresee that you need them." I know that, sometimes, we can feel when a class is good candidate for reuse. But even so, it's better don't implement it now. Please see a better discussion at http://c2.com/xp/YouArentGonnaNeedIt.html Best regards, ..:: Thiago ::..
Thursday, June 28, 2007 12:57 PM by Mark Leighton Fisher

# re: Tips for Testable code and for testing legacy code

Maybe I'm imagining here, but "interfaces everywhere" seems like a Code Smell to me. One way to help preserve security while not forcing every class to have an interface would be to allow mocking of arbitrary classes as long as the mocking class is in the same assembly as the class being mocked. Of course, there is alwalways ILMerge...

Sunday, July 01, 2007 8:40 AM by Sasha Goldshtein

# re: Tips for Testable code and for testing legacy code

I feel that making all methods virtual, avoiding the sealed keyword like fire and extracting an interface from every class and using it extensively are great propositions for possibly a vast majority of all the code out there.

Still, if you are writing for performance and have performance in mind, virtual methods cost you, non-sealed methods cost you, and interface dispatch costs you even more.  After all, correctness is a must, but performance is very valuable (and sometimes a must) as well.

So while your suggestions might be valuable in general, I think it would have been appropriate to note that there are many many exceptions to these rules.

Tuesday, December 02, 2008 9:35 PM by Sam Gentile's Blog

# New and Notable 170

Design Patterns/Software Design/Agile The Presenter First Pattern End to End, or, Another Run on the Hamster Wheel of Life Build your own CAB Part #8 - Assigning Responsibilities in a Model View Presenter Architecture Build your own CAB Part #9 - Domain

Friday, January 09, 2009 1:25 AM by TDD Articles « blog / plan

# TDD Articles « blog / plan

Pingback from  TDD Articles « blog / plan

Friday, February 12, 2010 3:51 PM by Niceboomer and the future of changes » Blog Archive » Tips for Testable code and for testing legacy code

# Niceboomer and the future of changes » Blog Archive » Tips for Testable code and for testing legacy code

Pingback from  Niceboomer and the future of changes » Blog Archive   » Tips for Testable code and for testing legacy code