Intro:
One method for coding stable code is TDD.
The basis of TDD is to write the test first, test it (and get an obvious fail) and then write the implementation.
Why would you do it this way?
First:
Because you implement the classes as a request-contract.
Second:
You have value full tests to-go
Third:
With these tests, if you refactor code hopefully your test will alert you for any breakage
My Story:
I started on a project (Java EE 7 with JSF) and wanted to practice junit tests. But for Injected beans and Jsf-contexts, the story got tricky.Now the Great test framework Arquillian has all the answers for that, BUT some of the things you need is only in alpha state. I struggled with it a lot. So much I actually choose not to do any tests...
BIG MISTAKE!
So when I tried to code a function for deleting a certain thing from the database (in the middle of relations) i got some problems. Every time I changed the code, I had to log in, navigate to the right site, try the function and then try to understand the giant EE stacktrace.
So I did a GIANT Refactoring (actually starting a new project and just copying in the entities).
I tried for 2 days to implement all of Arquillians might for testing actual websites in the server (Graphene, Selenium, Drone). But in the end it didn't work.
But I got the junit tests (run by Arquillian) to work (as injected beans).
So now I could actually test the beans function without all the login and stuff.
And when it's all implemented I can actually do manual Selenium tests to see that it actually works in the website.
A bonus thing is that the test wipes and then populates the database with test-data.
So if I have to drop the database (ex if I change the persistance classes) I don't have to create all the test data manually.
Summary:
So what can we (and especially I) learn from this?Even if you don't do the tests first like TDD, have a test framework! It saves so much time.
Code ahoy!
