NFJS(Mocks, CI, and other tools of Agile Folks)

The first of several Agile talks I went to was Tools to Facilitate Agile Development. The first set of tools was all based around Unit Testing. Most of this was about Mock objects and Junit in general. We already use EasyMock and try to do some testing ( we are getting better all the time ). One Unit testing tool I had never heard of, and plan to explore more is JUnitPerf. One of our big problems at work is that our Jboss server PermGens A LOT. We have never been able to reproduce this in tests. Maybe using the load testing stuff here I will be able to reproduce it, then we can finally start debugging it. There was some good information on Measuring Design Quality and trying to get you're code closer to the Main Sequence...a good balance between abstractness and concrete implementation that actually does something. I like this, but as we try to introduce more tools and techniques I think this one is going to end up down on the list. We have been looking at Code Coverage tools on our own already and I think this is one of the things that we will try to implement pretty soon. Maybe not on everything, but at least on some stuff. I had never heard of, or much less thought about, using a tool like Jester that attempts to figure out of if you are writing "good" tests by modifying your code at run time to verify that if it changes the code your tests will start to fail. I like this, at least for now, as something that we should encourage people to run on their own while writing tests. One of the things Venkat mentioned about Jester is its ability to help you learn how to write good tests. But it also throws a lot of false positives, so I'm not sure I'm ready to throw that on Cruise Control just yet. I have run PMD many times on my own code, and I like it, but it also throws a lot of false positives, so until we get better Junit coverage, and eliminate the errors generated by FindBugs then I'm not sure I'm ready to jump on PMD or its CPD tool. As it is today we do not run FindBugs on our projects, except for the couple that I am working on. Mostly the reason so far has been that there are too many bugs reported and "why should we fix those before we fix the ones that the customer is pointing out to us" I'll continue to fight back on that one as I think we should get Find Bugs running on everything ASAP. Venkat also touched on CI, and over the last year we have gotten Cruise Control up and running, and within the last 3-4 months we now have all of our projects in Cruise Control and running the unit tests when they exist.

I also went to Venkat's talk Mocking to Facilitate Unit Testing. This was another talk where I have already been doing this for a while, and have introduced it to the rest of the team. I really went to this talk because I had introduced myself to EasyMock and taught myself how to use the framework, so I wanted to know if we were doing things right. As it turns out we are on the right track. The one thing that I took from this class was...”don't use a Mock Framework just for the sake of using a Mock Framework”. I'm not going to go back to my old code and change the tests, but I know from know on I'll really consider heavily whether or not I really need a mock object or if I can create a better one on my own. And as I look back on it, I really think that I will tend to lean on EasyMock more often than not because I like what it offers. The other thing that came from this talk ( at least I think it was this one ) was the idea of introducing Groovy to the company by writing unit tests in Groovy. This would offer a lot of the mock stuff right inside of it.

Jeff Brown gave a Test Driven Development with Groovy and Grails talk. There was actually not a lot here that I had not seen before, which kinda surprised me a bit. There were really two things that I took aways from this. First that I like TDD with a dynamic language because you can write a set of tests for stuff that doesn't exist and still run them. For Example...a class is going to have 3 methods that interact with each other. I can write up the unit tests and run them before the class is implemented. In Java you could write up the tests, but you definitely can't run them because the code won't compile. This is a pretty minor thing, but I really like that idea. The other was the coolness of the Expando class, because of Duck Typing you can build and Expando and use it as a mock for anything...really cool. Interestingly not a groovy specific thing, but he talked a bit about Canoo Webtest for testing grails applications, and I think we could really utilize that to test our Web stuff since today we do NO tests on our front ends. I think I will give that a try the next time I edit the front end stuff, which hopefully will be a long time from now.