> > No, thats something we need to look at. I'm not yet comfortable with
> > re-factoring that happens. I only hope its code-level refactoring that
> > everyone talks about, and not design re-factoring.
> I don't understand the difference, sorry.
The difference is this:
We follow the traditional spiral methodology for each release that we
do - we do an architecture blueprint, review it, we do a high level
design, review it, a detailed design, review it, then code, then unit
test it, review code, then functionally test each module, then do
integration and perform integration testing.
We do a detailed design that identifies all the methods in the code,
mentions the specifics of each method that we write. We then start
coding each method.
What i understand by code-level refactoring is changing the logic of a
method, by say, bringing up the common logic being used into something
like a util class. However, IMHO, design-level refactoring would be
bigger, in the sense, it could result in new patterns being
introduced, "bad" patterns being thrown out, whole new
components/modules being introduced or reworked etc.
My rant is that I would like to avoid such major changes at the time
of "re-factoring" the code. I would rather freeze the design after
reviewing the detailed design. I understand that this is against the
XP way of working, where the design is not frozen until you have
completed the test cases and re-factoring as you code. However,
freezing the design early gives greater control and predictability
over the coding phase, and emphasizes that we do design correct the
first time itself. Besides, the design review phase is expected to
give any inputs towards design refactoring. Similarly, code review is
expected to ensure code refactoring has been done.
Any of you having experiences with mixing XP with the traditional
waterfall/spiral methodology of project development? Please let me
know your thoughts on the same.
> > Also, TDD is not an option for legacy code - what would you do if you
> > had to maintain a huge product/project? Would you manually write test
> > cases for the legacy code, so that you start with a clean slate?
> The problem with legacy code is that it's most often untestable at the unit
> > My basic rant is this:
> > a) We typically cannot account for writing JUnit test cases for huge
> > codebases upfront.
> That's not what you are doing when you do test-first-development. In
> test-first, writing the tests is closely amalgamated with writing the
> production code. It would be virtually impossible to account for it
> seperately. BTW, do you account separately for debugging?
No, we dont account separately for "debugging" per se. However, we do
have time set aside for integration testing and debugging, which is at
the end of each release. I would guess thats unavoidable for XP-based
projects too - you've tested the individual modules so far, and now
need to get onto integrating all of them together and testing them
With respect to each module, the development team does a bit of unit
testing, and more of functional testing, before handing over to the
> > b) Even writing JUnit test cases only guarantees the quality of the
> > unit, and not the whole. Functional testing is still required to check
> > whether the customer's requirements have been fulfilled.
> > With this in
> > mind, manually writing JUnit test cases is a very expensive task
> > indeed, especially for a legacy codebase.
> I don't understand how the existence of functional testing makes unit
> testing expensive.
How can we justify the costs of writing unit test cases, if at the end
of writing all those unit test cases [even assuming they cover 100% of
the code], we still do not guarantee, for obvious reasons, that the
application fulfills the customer's requirement?
That brings me to the reason I posted first on this thread [and the
thread's gone into re-factoring and other XP thoughts, but I've loved
I'm looking at an automated solution for generating unit tests, which
would take the tedious task of writing unit test cases off our back,
and would allow us to focus on reviewing the generated test cases, and
maybe even design-level re-factoring the XP way.
Yes, this automated solution would look at my potentially buggy code,
and would reproduce buggy test cases, but thats where the reviewer
comes in - he would look at the generated test cases and
inputs/outputs, and would check if these make sense. If not, he would
need to get into the code and correct the bugs, and then re-generate
the test cases so that the inputs/outputs now make sense.
Is there any such solution out there?
> > > I think I don't fully understand the question. What problem are you
> > > to solve? What alternatives to mock-objects do you see?
> > The problem I'm trying to solve is this:
> > Assume C1 calls C2, which in turn calls C3, and that there is a single
> > method "execute" in each of these classes that gets called.
> > C1.execute() -> C2.execute()
> > C2.execute() -> C3.execute()
> > Now, with the mock objects approach, if I had to test C1's execute
> > method, I would need to simulate the functioning of C2.execute() with
> > a mock object.
> Yes. Sometimes this is more feasible than not mocking C2. More often you
> probably don't need to mock it. Mocking isn't an all-or-nothing thing - it's
> a tool you use when it makes testing easier.
> > If tomorrow, I replace the logic in C1.execute as follows:
> > C1.execute() -> C4.execute()
> > C1.execute() -> C5.execute()
> > C4.execute() -> C4a.execute()
> > C5.execute() -> C5a.execute()
> > i.e. C1.execute() calls C4.execute, followed by C5.execute. C4 and C5
> > in turn call C4a and C5a's execute methods respectively.
> > In this case, I would need to change the mock objects, and therefore
> > the JUnit test cases, to "mock" C4 and C5 in order to test C1. I'm not
> > comfortable with that approach, because the JUnit test case becomes
> > "implementation-dependent", whereas it shouldn't be the case.
> Well, JUnit test cases often are white box tests, and therefore
> implementation-dependent. I understand why this thought makes you feel
> uncomfortable. But I'd urge you to try it - you will probably find that it
> doesn't present an as big (and frequent) problem as you fear, and solves so
> much other problems that it in fact becomes very practical.
Point taken. Thanks.
Quote:> Regards, Ilja