when hierarchy smells?

Overridden method without a call to parent is always a lame-hierarchy warning to me. It is so simple: The proper hierarchy needs ‘is-a’ relations. Is-a means I can substitute all base classes with their sub-types (yes, that’s the Liskov’s Substitution Principle)… Now, is it really an is-a if subtype doesn’t call super? Not at all – it is rather clear message that subclass want to do something very different than the base class…

Inheritance is a tricky business, it’s wise to remember Design By Contract Principle:

A sub-type can only have weaker pre-conditions and stronger post-conditions than its base class.

On the other hand, if overridden method is truly LSPy without calling super it likely means code duplication smell.

Missing super.myMethod() in myMethod() is a potential smell. It’s easy to spot in java code when methods are annotated with @Override.

(Update 04-10-2007)

I’ve just had a debate with my friend but my stance is still the same. No super() usually means one of those:

• LSP violation
• duplication

test clean up – before or after?

Another day, another bunch of tests not really coded to be rerunnable.

A smell: in order to fix tests you have to run some scripts to clean / setup database or environment. It’s wrong. Change the test, fix it so it doesn’t depend on any clean state. Make running test a pleasant experience – let the other devs run it from their favorite IDEs as many times as they want, let them see a green bar whatever state application has or whatever data it has.

Now the question is: to clean up on start, on finish or both? Well… I don’t really care. Just make it rerunnable.

Hold on… actually, I prefer not to clean up after test… Let’s think about some tests hitting database: Why not to clean up after every test?

• I quickly find issues with other tests if they fail because there’s been some data left from other tests (e.g. it means that tests are not independent and rely on successful execution of clean-up logic in some other place).
• I have some data after execution of single test – that sometimes helps in debugging, seeing what happened (especially when using languages/environments where debugging is a pain)
• I can run test and have some test data left for demoing functionalities
• Less coding & smaller code base (nobody, I say nobody can beat this argument =)

I want to be a QA when I grow up

I must say I’m increasingly impressed with nowdays evolution of a QA role. Yeah, testers riding on eclipse and cracking on refactoring goodies or other sophisticated java toys (What’s next? bug fixing? =). Nice. How about taking control of deploying release candidates – not only decisions but also running scripts etc. Moreover, QAs are very close to business people doing stuff like: playing prioritization games on bugs / features or confirming expected behavior. It’s almost like superseding the role of business analyst 8-) QA is a career now and not an interim stage to a developer.

What’s an Er class?

Ever heard of Er class? It’s right there in your project, in your codebase; moreover it’s in every single project (larger than ‘Hello World’ =).

Every time you don’t know where to plug your neat piece of code, here comes an Er class:

1. “Errrrr… Where should I put that logic?” (Er class is yet an Errrrr class…)
2. “I know! Let’s throw it into ApplicationManager, sounds like a right place to do it!” (Boooo!)

Here are exemplary Er classes: BlahBlahManager, BlahBlahHandler, BlahBlahBuilder… Sounds familiar? Bottomless code buckets usually have common naming convention…

1. Avoid non-specific class names. That leads directly to making your classes specific and SRP-y.
2. You want to create BlahBlahManager? Hint: you’re likely to create an Er class.

BTW, Er class is Duncan’s idea.