Mockito

I've done a lot of automated testing with JUnitand StrutsTestCase, but have wanted to explore other areas like mocking and continuous integration. So I decided to try out a Java mocking framework. I read a few blogs and decided to give Mockito a try. It's definitely an easy setup - just copy one jar file into your project (or add it to the build path in Eclipse). I then went through this tutorial to get a feel for it.

Never having done mocking before, it took me a little while to get use to the syntax and how it worked. I definitely need to spend more time with it on a real project to get the full feel of it. Having glanced at other mocking frameworks like EasyMock, it seems Mockito is a bit more streamlined and clean. For instance, there's no need to call replay to start the mock. But they look quite similar. Did I read Mockito came from EasyMock?

One of the challenges with mocking in an existing project is that the code must written in expectation of doing mocking. It's not simple to just slide in some tests. To do mocking, the code needs to use dependency injection (so the mocked objects can be injected) and use interfaces. One of the systems I'm working on right now is a Struts MVC application. It has nice layers with actions and DAOs, so it was straight-forward to use JUnit to test the DAOs and StrutsTest for the actions. But I'm trying to find a way to apply mocking to it and can't - data source objects are instantiated within the DAOs and are concrete classes. I may be able to refactor the code but that becomes a much larger effort. This is a good reason why you need to think about testing as you start developing an application.

Pixar, Innovation and Agile

Have I mentioned I love Pixar?

It started off with Toy Story, their first full-length theatrical film and the first such film completely computer-generated. Their movies have such heart and great stories and characters. Many of their films have a deeper meaning for me - Ratatouille (I love to cook), Cars (The summer after its release my son and I took a week long vacation in my Mini Cooper convertible along Route 66), and Up (My son and I went to an Up pre-release event at the Pixar studios in Emeryville, CA.), are just a few examples of this.

I've also been an investor in Pixar, initially buying shares shortly after their IPO in 1995, and on and off afterwards until their merger with Disney. It was a great run, and in some ways I wish they had stayed an independent, public company.

But for the past number of years my interest and excitement in the company has come from their innovative culture.

A number of articles and even books have been written on their culture. It is very open, creative, collaborative, and from the performance of their films, very successful. The artists at Pixar work hard, have fun and really enjoy being there.

But this type of culture does not only pertain to the entertainment or animation industry. I have often thought about how software and technology companies could benefit from following a similar culture and management style.

A recent McKinsey Quarterly article (registration required) interviewed Brad Bird regarding his views on stimulating innovation. The ideas of collaboration, morale, open and frequent reviews of products, and being "good enough" all relate well to the Agile development methodology for software. I plan on writing a few blog posts on software innovation using this article as inspiration.