Today, after a long and truly joyful refactoring session, I stumbled on this article about hashcode() method's coverage.
Which reminded me of David dossot's blog entry dealing with the problem of coverage.
It made me wonder a lot about the big difference between rich client software and J2EE middle tier software : test coverage.
If hashcode() methods' coverage is so hard to obtain or at least can be so boring to do when you have tenth of value objects in your code, at least it can be done!
I for myself feel completely lost and have no clue on how to unit test the code of an eclipse plugin or the code of an Eclipse RCP app...
As a good (well trying to...) J2EE developer and POJO fan, I tend to encapsulate all my specific logic in specific as-POJO-as-can-be classes.
Therefore making these classes testable.
But what about the real tricky-buggy part of these apps: GUI!
I for myself am missing a lot of tricks and patterns for testing this.
And by testing, I mean unit-testing. Because GUI also diserves it. And not only integration tests.
In the end when you think about the code of an Eclipse plugin's UI and the strategies you'd have to use to unit-test it... hashCode() seems like bliss ;)
jeudi, août 31, 2006
jeudi, août 24, 2006
My Kingdom for a release!
After yet another day of pom.xml and settings.xml and other properties tweaking, I must admit I'm quite satisfied with my Maven 2 builds.
Still it is not completely satisfying...
The main problem I can think of if that almost 2 thirds of the plugins available on the apache and codehaus repositories are not even officially released.
And I'm not even talking about the exotic plugins generating weird things or weaving any exotic kind of AOP ;)...
Some of the core features can completely be ruined from an automatic update to another (my last memory of it is the site plugin now ruined by a beta functionality from the skin plugin...).
Problem is that even released plugins are often tied to beta ones.
So I beg the maven plugin developpers to gather and to try and elaborate a Callisto-like release!
This will benefit to both users and plugin developers.
Even if some plugins are buggier than others, at least it will not feel like walking on a pile of rolling stones all the time ;)
Still it is not completely satisfying...
The main problem I can think of if that almost 2 thirds of the plugins available on the apache and codehaus repositories are not even officially released.
And I'm not even talking about the exotic plugins generating weird things or weaving any exotic kind of AOP ;)...
Some of the core features can completely be ruined from an automatic update to another (my last memory of it is the site plugin now ruined by a beta functionality from the skin plugin...).
Problem is that even released plugins are often tied to beta ones.
So I beg the maven plugin developpers to gather and to try and elaborate a Callisto-like release!
This will benefit to both users and plugin developers.
Even if some plugins are buggier than others, at least it will not feel like walking on a pile of rolling stones all the time ;)
mercredi, août 09, 2006
Driving the change
I'm having a hard time finding people who are never in a destructive state-of-mind in the IT field.
Each and every people has a good reason at a given moment to resist to change.
It seems difficult for everybody to realize that embracing changes before they occur is the key to longevity and sanity in the IT field.
The problem with IT systems is the same as with employment. Stability and Longevity are now enforced by constantly moving ahead. Trouble comes when people are in a Cobol-ish/Mainframe-ish state of mind, thinking that every single piece of an IT System is destined to last whatever happens.
In the end everyone finishes up blaming the audacious for the sake of costs and responsability.
In fact it is difficult to handle change when you're not driving it. I guess that's why I tend to go to the change orientation part, so that I can precede change instead of being its victim.
So at the end of the day is it really a matter of resistance to change or more a matter of resistance to change driven by others?
Each and every people has a good reason at a given moment to resist to change.
It seems difficult for everybody to realize that embracing changes before they occur is the key to longevity and sanity in the IT field.
The problem with IT systems is the same as with employment. Stability and Longevity are now enforced by constantly moving ahead. Trouble comes when people are in a Cobol-ish/Mainframe-ish state of mind, thinking that every single piece of an IT System is destined to last whatever happens.
In the end everyone finishes up blaming the audacious for the sake of costs and responsability.
In fact it is difficult to handle change when you're not driving it. I guess that's why I tend to go to the change orientation part, so that I can precede change instead of being its victim.
So at the end of the day is it really a matter of resistance to change or more a matter of resistance to change driven by others?
Inscription à :
Messages (Atom)
Messages
