Strategies for separating unit and integration tests, using Maven, Eclipse / IDEA, cobertura

What I have

• Maven2
• Eclipse/IntelliJ IDEA
• Fast tests (unit tests)
• Slow tests (integration tests)
• Test coverage maven plugin (Cobertura)

I wish to

• run my fast tests (unit tests) from my IDE
• run my slow test (integration tests) from my IDE and maven
• run them all before committing code.
• create test coverage reports combining unit and integration tests
• create test coverage reports from unit tests only

The only good branch is a dead branch

edit: so kill them fast :)

Eclipse keyboard shortcuts or shortkeys

I’m not gonna excuse my shortkeys. Or did I just do that? Here are some Eclipse shortcuts that I use regularily and some that I keep forgetting as I don’t use them…

Stars	Shortkey	Function and Description
¤¤¤	ctrl+1	Suggest Fix (TDD tool)
¤	ctrl + shift + i	Inspect
¤	alt + ↑ ↓	Move selected lines up or down
¤	alt + shift + L	Extract local variable
¤	alt + shift + M	Extract method
	alt + shift + X, t	Run as test
¤	alt + (shift +) k	Find next match of marked text in file, up/down.
¤¤	ctrl + (shift +) 7	Comment/uncomment
¤	ctrl +d	Delete line
	ctrl + o	Outline
¤	ctrl + (shift+) T	Open Type
¤	ctrl + shift + R	Open Resource
¤	ctrl + shift + G	Find all references
¤	ctrl + shift + O	Organize imports
¤	ctrl + shift + F	Format
	(ctrl +) F11	Run or debug last test
	ctrl + shift + Y/X	UPPERCASE or lowercase marked text
New!	ctrl + shift + L	List all shortcuts. Find your own!

Now you propably know more than me… Please inform me of my lackings!

Birth Date with Jaxb and XMLGregorianCalendar

Lots of googling and frustrated colleagues and no solution to represent a simple birth date without minutes and seconds. In short, jaxb always uses XMLGregorianCalendar to represent dates, how to represent the birth date as
1980-01-01
instead of
1980-01-01T00:00:00.000+01:00

Fødselsdato fra fødselsnummer

Til min store frustrasjon, fant jeg ikke noen kode på nettet som dro ut fødselsdatoen fra et fødselsnummer. Det er verre enn det høres ut, med 18., 19. og 20. århundre, D-numre og H-numre. Men jeg fant denne siden http://no.wikipedia.org/wiki/F%C3%B8dselsnummer (http://no.wikipedia.org/wiki/Personnummer).

Dette er offentlig informasjon og må da være brukt av mange, tenker jeg, men den gang ei. Nå, da jeg har implementert det, skjønner jeg forsåvidt at det ikke er publisert, det er jo bare noen få if-setninger! Men med min frustrasjon friskt i minne, publiserer jeg, sammen med en rekke enhetstester for corner-caser. Om jeg har gjort noe feil, vil jeg gjerne vite det!

Maven Dependency Hell

Yeah, I knew you’ve felt the same some times! Some developers are suddenly experiencing local problems, while others doesn’t, even as they’re having the same code base. The experienced developer thinks “classpath problem!”, almost as a reflex! And they’re always right, it’s yet another a damned jar that’s been automagically downloaded by maven from an other automagically loaded jar dependency. Anyway, that’s how it feels like for me. It’s often time-consuming to discover the reason, even more time-consuming if “classpath-problem” isn’t your first thought (god, no)! If not, say bye bye to productivity for that day. Been there, done that!

How to avoid it? Eliminate the automagic dependencies. Exclude these dependencies and explicitly define all used dependencies.

Unit Testing Domain Objects Without Public Constructors and Setters

How to unit test a domain object that is instantiated and populated solely through a persistence API as Hibernate? Having such domain objects isn’t uncommon in database-centric solutions. The organization might have other systems, roles or employees entering and governing these data. In Domain Driven Design, the domain objects are our most important entity and should reflect the real world. If the application have no need for creating new instances of a domain class, the class definition shouldn’t include public constructors. If it contains read-only data, the fields should as well be private, without public setters. My experience is ” if you provide the opportunity for a developer to misuse your domain object, it will be misused, sooner than later”. But to test the domain objects and logic in isolation of the persistence layer, you’d have to add public constructors and/or setters, or modify them to public access. To me, a good, restrictive domain model and unit tests are both extremely important. What should you do? That’s my punchline. Read on!

Ah sorry. Reflection sucks for this purpose. I’ve deleted the previous solution. The test became resistors of change! I’ve concluded it’s an anti-pattern. But I have, with great success, solved the problem at hand in way with package protected setters. That is, create a MyDomainObjectFactory.class in test-scope, and ask for your domain object in a given legal state (legal – as you BL may populate it). Be strict on your domain objects, public setters are monsters. They add permutations of states!

Additional excellent rule of thumb. Never write new in your tests (except for testing the domain object itself). Always ask for it from the factory. Then you’ll have one place to refactor it. You don’t want to refactor a hundred tests if you only change your constructor. That’s a robust test!

Database test data is also a bitch. I through them all away, used the factories to ask for the object, persist it, and test on it. It’s fast if you’re using an in-memory database as hsqldb. And you may change your application fast, really fast.

MyD myd = super.persist(MyDomainObjectFactory.createMyObjectInState());

then test on myd. (implement persist in a superclass).

Hmm, yes. This post is old. I’ll write a new one about these subjects. Let me now if you read this and wanted more.

Wicket – Tired of Spring MVC/WebFlow, JSP or JSF?

Wicket is a GUI framework recently promoted to a top level apache project. I’ve only studied it through it’s apache pages and look at code examples. But I do hope to try it out in a project.

Spring MVC has state issues, WebFlow is xml-programming and JSP messes up the html for our designers. This one of more things Wicket claims to differentiate upon. So, what’s my immediate analysis/feeling of Wicket?

pro:

• pure html/xhtml. Paradise for designers!  (The components, buttons, labels etc. are given unique ids)
• handles the state. (No more nasty HttpSession manipulation)
• no back-button issues
• more java, which is what I’m really good at
• less xml
• no jsp, only html and java (and design-stuff, whatever that is)

con:

• more java and code lines. Looks a lot like swing. You’d have to write new lots and lots of times. (Yes, I know, also listed as pro)
• uses session in the background, which might put restrictions on server capacity (I really don’t think this is a big issue at all, we tend to exaggerate this)

I think that about covers my quick analysis. Anyone have any experiences with it or don’t share my opinions, I’d like to know :)