Thanks Russ. That is exactly the way I am going to start.
Amazingly I even met some resistance to that approach - "it will be
inconsistent with the rest of the application", "someone new coming along
won't understand what is going on" ...
I have managed to convince them by showing the difficulties of unit testing
as the code stands, although they were happy just doing slow running
end-to-end tests and assuming that since the few test cases passed then the
whole system was fine. The standard policy is that for every 10 hours of
coding we need to allocate 3 hours of future defect fixing! I am hoping to
change that. Slowly, slowly...
On 27 June 2013 23:51, Russell Gold <russ@...> wrote:
**
How much code control does the organization exert? Do you have regular
code reviews?
My experience is that the best way is to start small. Make one class
testable at a time without touching the caches. Use facade interfaces as
wrappers to deal with your statics. For example, in Java I might do
something like this:
Existing static:
public static ThingIWant getThingIWant() { accesses the db and caches the
result }
Existing class:
class MyClass {
:
void doSomething() {
ThingIWant aThing = ThatStaticClass.getThingIWant();
process(aThing);
}
}
Modified class
class MyClass {
interface SomeInterface {
ThingIWant getThingIWant();
}
static class LiveProxy implements SomeInterface {
public ThingIWant getThingIWant() {
return ThatStaticClass.getThingIWant();
}
}
// test constructor
MyClass(SomeInterface interface) {
this.interface = interface;
}
// production constructor
public MyClass() {
this(new LiveProxy())
}
/// modified method
void doSomething() {
ThingIWant aThing = this.interface.getThingIWant();
process(aThing);
}
Your code is now testable - you supply a test version of the interface
when you instantiate it, and can control the object returned. The
production code uses the same interface, but supplies a production version
which accesses the statics. You don't need to persuade anybody of anything,
other than your code reviewers. The rest of the system remains unchanged.
At some point in the future, once you have an acceptable level of code
coverage, you can tackle changing the statics, but I'd put that off as long
as possible.
The important thing is to start by testing as much as you can while making
as few changes as possible.
- Russ
On Jun 27, 2013, at 2:59 AM, David Burstin <david.burstin@...>
wrote:
As far as code smells go, some people just seem to have blocked noses!
Anyway, thanks everyone for your answers. I'm glad to see that I am on
the
right track - now I just have to convince everyone else. I think the best
way forward is baby steps. I will start by encapsulating the statics
inside
a concrete implementation with a well-defined interface. Even that might
take some convincing! But at least it will give the opportunity to do
some
good testing.
I am looking at the possibility of using a DI framework to replace the
singleton caches, but that will be a HUGE leap for these guys. What do
you
guys feel is the best strategy for caching without having to pass around
an
entire collection of cache instances?
Cheers
David
On 27 June 2013 04:24, Steven Gordon <sgordonphd@...> wrote:
On Wed, Jun 26, 2013 at 10:54 AM, Michal Svoboda <pht@...>
wrote:
**
Everyone else on the team thinks that they are a great solution.
I hear you. It's not easy to convince others of their design problems
unless there is hard factual evidence. Look around the user code of
that
object and you'll find the smells.
Or there might not be any convincing enough smells, yet!
If not, bide your time, watch for smells as the code scales, and when
convincing smells appear, then make the case for refactoring it away
(trying not to say "I told you so").
One benefit is that there may be more information later to indicate what
the most appropriate alternative would be.
SteveG
Michal Svoboda
[Non-text portions of this message have been removed]
------------------------------------
Yahoo! Groups Links
-----------------
Come read my webnovel, Take a Lemon <>,
and listen to the Misfile radio play <
>!
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
