High and low about Java and Web programming
Not working Scrum and not being effective is a pain right now. Our process is suffering and me with it. But it seems not enough people care for things to change. Would like to go KanBan, but it is hard to implement change… So I think the new plan will be to change just a little every week and see if it sticks. Start with changing my own way Will be a good start I think.
What is your favorite way of writing FitNesse tests in SLIM? Do you use script-like tables where you have controll of the entire flow or do you leave most of the setup and preprocessing to the fixture?
For example if you have a usecase including a login, a rental car booking and a the returnal of the car. In this case your main objective is to test the returnal. Do you explicitly have test table rows with login and booking and then asserts on the returnal? Or do you let the fixture(s) handle these prereqs in the background?
After some time away from contact with production code (due to SlimNesse project) I’m back in biz again. Started with writing FitNesse and JUnit test to confirm the bug (to be corrected) and then made the code changes. Easy, fun and quite by the book. Well… some redundancy in FitNesse and JUnit test, but what the hell.
Time to make it all come together. Now let’s get all our tests automated in the build loop, or atleast in conjuction to it. We have a smoketest server where we will host a test version of the system, and after built on Hudson and added in Nexus all the artifacts are pulled to the server. This is nice, but now we need some extra stuff to restart app servers, deploy new code and start the SlimNesse tests. So, lets look at the Trinidad project to be able to run the tests without having the FitNesse server running.
Recently I have been involved in a fun little project. We wanted to kick-start the implementation of using FitNesse so me and a collegue got the oppurtunity to work with this fulltime for a few sprints. Since it was setting up pretty much everything from start it has been quite a lot of plumbing, but that is ok.
Since FIT is kind of outdated by SLIM we decided to use that instead, hence we call the project SlimNesse. I hope Uncle Bob with honarble friends won’t mind. I think we are doing good by this…
And SLIM really feels better and easier then FIT as I remember it from a few years back in time. More time to write tests and production code and less time writing fixtures, I like! My vision is to get the philosophy of SlimNesse driven development spread and going in the team. And also to be able to spread it outside this particular workplace, which should not be impossible since my job as consultant bring me to all kinds of customers.
First, I need to get going with this one and then make up my own mind if this is a better road to follow then hardcode developer.
Today, as many other days I had assigned myself a task from Jira and started to work. First, by checking what to do and then I started to write the complementary JUnit tests to get the tests to break. Is it not great!? Ofcource, it’s even more fun to be able to write whishful failing code first, but life is not fair every day 
With more and more of my workday turning into management, ppt programming and meetings it is great to g back to basics now and then and just feel good about it.
Found this nice blog while searching for some log4j info the other day : http://veerasundar.com/blog/
Seems to have quite some other good pieces of info aswell that I might have to discover.
Not much here lately due to time issues. Or prio issues one could say. So, posting in between meetings from My iPhone is only option right now. Hopefully I Will have time to look into Jee6 tjis year and some more about tdd
I started out to investigate TestNG to see if it has an advantage over JUnit 4 and first I thought so but along the way (reading about it) I found it to contain just a little to many setup files and configurations (XML). These are things you don’t see when running the combination JUnit 4 and Maven 2, but maybe there is another way to go to have the same easy run options with Maven / TestNG.
Sofar, groups are the biggest improvement here. Since JUnit 4 took quite a few things from TestNG when it took the step from JUnit 3 you would think that Junit 4 should be able to match TestNG. Well, if I get back into this investigation I’ll try to tell my story about it here.
This book is a must have in a team of developers. It doesn’t really bring you much new stuff but it sure is a good collection of the tools you need at a dayly basis. I learned some new JUnit 4 and TestNG stuff today actually, the way test data can be set up in both these frameworks. I still have half a book to read so I probably have a few more new things up my sleeve when done. This is a compile-one (read-one), run everywhere (use any day) book.
