On Friday 18 March 2011 07:53 AM, Asokan Pichai wrote: > > One of the reasons I added the `ill-defined' in my post. > This seems an interesting problem though. > --One does want to ensure that a change has not broken anything, but > can that be done by ONLY testing where a breakage is possible? Sounds > really hard problem to solve.
I don't think that's such a big problem in general; we write failing tests first and then add code in TDD, though this is not always practical or possible. What I think you're referring to is a bigger problem, as to how much should we test (or how much coverage to have in other words). There is no hard and fast rule here - while 100% test coverage is great, it's hardly practical or recommended in most cases. We pick the places where we want to make sure the app performs as expected - and go easy on the places where it's not so important for the effective functioning of the app. It's a trade-off, but usually having the discipline to write tests means that (whether TDD or not) the app will be reasonably bug-free (ahem). Personally, I'm not an XP/Agile fanatic - while I find the general guidelines very helpful, I'm not a strict adherent, I should admit :). Especially in a startup scenario, where speed of execution is so important, one has to be very judicious about where to put the extra cycles. > > Yeah; TDD is not just regression testing. But using such labels which > were defined in a context where coders wrote code and testers tested that > code is one of the areas of some confusion in the understanding of TDD > at least to me, for a time. > > I tend to think of TDD as exploratory development and best suited for those > situations when part of the solution is NECESSARY for defining the > problem itself and/or the exact approach to solution is yet unclear. > > Thoughts? Actually, for me at least practically speaking, it's been the other way round - TDD helps me when I'm know what to expect fairly well - which means that I know what to check for, see the tests fail and write the supporting code. But when it comes to say, something like writing a fairly complex javascript-driven UI, I find TDD less compelling, not because it's not useful, but I don't know what to test for some of the times. It's likely a new plugin or a UI component/approach I'm trying on for the first time, which is a big part of what I do. Insisting on TDD at this stage becomes tedious, because I don't even know how to configure/use this component or in some cases, how it behaves. So I just finish the part and then write selenium tests. Again, it's a trade-off :). Perhaps if there is a reliable (and fast way) to test javascript headlessly, I might not have to break the TDD discipline, but we still have a ways to go (at least in the Rails world) for that. Vamsee. _______________________________________________ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
