With all the chat about dependency injection (bringing memories of Java back), here's an oldie but goodie take on it using Ruby from Jim Weirich (circa 2004):<div><br><div><a href="http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc">http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc</a></div>
<div><br></div><div>Abdel</div><div><br><div class="gmail_quote">On 21 March 2012 09:53, Stephen Masters <span dir="ltr"><<a href="mailto:stephen.masters@me.com">stephen.masters@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>TDD tends to lead to using well-established patterns of loose coupling, dependency injection and clean interfaces. But you get there because the methodology forces you to get there. However, it's also perfectly possible to write such 'good' code without using  TDD.</div>
<div><br></div><div>So given a well-structured project that (as Steve Tooke described) is easy to test, it's not so easy to say whether that project was written using TDD. However, given a project packed with exceedingly long methods, obscure interfaces and no capability to inject dependencies, I could make the safe assumption that it was not developed using TDD.</div>
<div><br></div><div>It's a bit like what my dad used to say about recognising which of his students were copying their programming homework from others. It's hard to spot copying when two pieces of homework are written well and bug-free. It's the flaws that raise the red flags.</div>
<div><br></div><div><br></div><div>On a side note relating to Sidu's (if I remember right) blog post yesterday, the wording of the question implies that a non-TDD project would not have any tests written for it in the first place. There are plenty of projects with lots of automated tests, but where the tests have been written in parallel or after the code.</div>
<div><br></div><div>In terms of the final code-base, such projects should be more or less the same as TDD projects. However, the process to get there would be somewhat different. With a test-after approach, you're more likely to write slightly more difficult-to-test code, which needs refactoring to support testing. As you get used to testing, you're likely to learn what patterns make code more testable, so this goes away somewhat. You're may also end up in a situation where you're using code coverage tools to help you chase nice stats. If you followed a strict TDD approach, then you should have very high coverage percentages without needing such a tool to guide you.</div>
<div><br></div><div><br></div></div><br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br>
</div></div>