[Ilugc] ssd and linux
- From: vkanakala@xxxxxxxxx (Vamsee Kanakala)
- Date: Sat, 19 Mar 2011 00:02:26 +0530
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.
Other related posts:
