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
Inscription à :
Publier les commentaires (Atom)

1 commentaires:
I have the feeling that JSR 305 could help here: if we use annotations like @NonNull, the IDE could then more intelligently generate less defensive code. Some checks for null could go away, leading to less conditional paths.
Enregistrer un commentaire