Re: [junit] Testing singleton patterns
- View SourceOnly if you *choose* to have 100 XML documents or are stuck with a legacy
system that involves 100 XML documents. There are ways to avoid XML hell.
I've successfully de-sprung a large enterprise application, replacing the
XML with more readable, more tool-friendly Java code. It made a significant
difference in the speed of system evolution because the team could refactor
much more easily.
On 31/07/07, Cédric Beust ♔ <cbeust@...> wrote:
> On 7/30/07, J. B. Rainsberger <jbrains762@...<jbrains762%40gmail.com>>
> > It is. If you have 100 XML documents, you're almost certainly doing
> > something wrong.
> Isn't this a bit of a hasty judgment?
> I'd say that if they have 100 XML documents, they are probably working
> on a midsize enterprise application, and this says absolutely nothing
> about the quality of their code or architecture.
[Non-text portions of this message have been removed]
- View SourceNat Pryce wrote:
> On 02/08/07, J. B. Rainsberger <jbrains762@...Thanks, Nat; I've read that one. Part of the problem is that
> <mailto:jbrains762%40gmail.com>> wrote:
> > If it's not something we can confidently
> > change without re-testing the entire application, it shouldn't be
> > externalized configuration data, it should be code. I'm not convinced
> > that the choice of implementations of interfaces is configuration data.
> > I think the community has lost its way on the difference between
> > configuring applications and wiring objects together.
> This is a good article about finding this balance:
configuration is in the eye of the beholder, and vision strength varies
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice