We just finished iteration one! We are doing 1 week iterations just in case you can’t count. 
We really over committed on the first iteration, we forgot about the holiday. Oops. None of the stories were fully completed, and there was business value to show. It’s a new team and we are still getting used to what we can get done in a week. I am more than a little concerned about how we have utilized our tool stack. My pair was lucky enough not to encounter any hindrance from how we were using the tools, though we were not using JBoss or Selenium for our story; this iteration we will. It is going to be a pain in the butt jumping out of the IDE to manage JBoss, Selenium, and Maven. Selenium RC needs to be running if you are going to run Selenium tests in the IDE and turned off if running them from Maven. JBoss dies a painful death after several deployments, so we will have to keep and eye on this. Hey, did the tests fail because we broke something or did JBoss die again? Also we have what I expect to be just a bandaid on a build script issue where integration tests start to run before deployment to JBoss has completed, the bandaid being a sleep command in the Maven pom.xml.
I seem to have nothing good to say. I was really hoping to report something that we liked better than the .Net world. I even consulted with the team before writing this post. So far it is hands down .Net and my team mates have no knowledge of things like LINQ, VS 2008, ASP.Net MVC, and most of the 3.5 technologies.
It looks like I will get some good exposure to Java Server Faces and EJB 3.0 next week. Maybe that will bring about something cool…
Last week I was having fun pair programming and TDD’n. This was my first time pairing with my new friend so we naturally had to work through our differences. One in particular was about a difference in unit testing and doubling (mocking) has stuck me with through the weekend. My partner wanted to test and double protected members. I was concerned that this was testing implementation and would bite us in the butt later by increasing the level of effort to refactor. Another member of the team has no experience with test doubles beyond home grown simple stubs. Working to explain the situations in which you would and would not want to use mocks, stubs, spys, etc has stuck with me too. Particularly the distinction between state based testing and interaction based testing.
I see TDD as a design activity and not a testing activity. I find it unfortunate that the word test is in TDD. So saying state based testing and interaction based testing is not helping the situation. I am going to start saying state based design and interaction based design.
When I was unguing that writing a test for a protected member was testing implementation I really wanted to say something like this is no longer a design activity. Instead I resorted to calling on Gerard’s Preface to provide a better vision of the woes of unit testing. At the time we were working on design, we were working oh the interaction between some of our classes. Later when we where working with the interaction between one of our classes and an external class I felt something shift and could not put a name to it. I have it now, the shift was from internal interactions and design to external interactions and implementation. We ended up using mocks in both cases testing design for internal interactions and implementation for external interactions. The external interaction we were mocking was simplistic, this is not always the case. If the interaction had not been so simplistic we would have gone straight to integration tests. To be clear we wrote integration tests as well. I was attracted to the mocked unit tests for their speed of execution and reliability over the slow execution times and external service dependencies of the integration tests. Not to mention how this would play an even bigger role if we start using a pipeline build. I want the most feedback I can get in a 5 minute build and mocked external dependencies gave it to me, this time.
I wonder if TypeMock can play a role in improving this situation. To be clear mocking the external dependency will not normally drive the implementation. In essence I have duplicated effort in testing the external interaction, once with mocks and once with the real thing. It seems to me that with the technologies that TypeMock is using you could write an integration test, specify the types or namespaces to record, execute the integration test while recording, and save off the record for playback. With the playback you could then run those same integration tests in mocked mode, everything that you had specified to be recorded now being mocked. You would have the benefit of in memory, fast running, tests and full integration tests with only a little extra effort.
In general I think open source is better at enabling you to behave Agile then commercial software. Lets start from the point when you realize that you have a need that is not being fulfilled. I want to explore this in two slightly different directions. First imagine that we have not finished defining our tool set and second imagine that we already have a tool set to integrate into.
Source control is something we all have had to deal with so I think it will serve us well here. So we are at the beginning of a project and need to choose a source control system. If you already have a source control system supported by your IT dept then you probably don’t even think this is something that deserves thought. Think for a moment about how this tool will enable you or hinder you in your practice of Agile over the course of the project. For example does it play nice with pair programing? Will it force you into some strange behavior just so that you can practice pair programming? Will it support your simple work flow: update, commit, update, commit…? Let’s pick on StarTeam for a moment. To my knowledge StarTeam is a hindrance for both the examples. It is not conducive to pair programming, it prefers to support one user per machine. This pushes you to log into a machine as some anonymous user. You end up creating a user per pair workstation. I quickly imagine 6 months from now trying to understand why something is the way it is in the software we are developing and reading the commit/checkin comments for some clue. In a normal world I would see that Billy had been working on this and go ask him. Now all I know is that someone on pair station 2 was working on this the afternoon of Sept 16th. Bummer! As well StarTeam has no update or get latest functionality in the UI. It has 3 categories of changes and at best you can update each category by selecting all changes in that category and selecting the appropriate action from the context menu. Mind you it is not the same context menu item for all categories! The point here is that this tool needlessly is requiring more of your brain power for you to get your job done. Subversion for example, as the open source alternative, has none of these issues. It is conducive to pair programming and supports "please just freaking update my sh*t!". Just in case, the latter is about KISS and StarTeam is in no way the embodiment of KISS. We could pick on any number of other commercial source control systems and find that they too fail to naturally support pair programming, in most cases you must operate in a contrived manner. To be fair there are some that don’t suffer from this affliction.
Lets move on to imagining that we are looking for a tool to meet a need and we already have an established tool suite. As well lets continue to contrast StarTeam and Subversion. There are many more tools that extend, enhance, and integrate with Subversion than StarTeam, both open source and commercial. Even the open source tools that do surround StarTeam provide minimal integration as compared with those surrounding Subversion. Take Cruise Control .Net (CCNet) for example, it is the only source control plugin to CCNet that does not support labeling, or tagging, on successful builds. The original Cruise Control (CC), Java, requires that you build CC from scratch to gain support for the plugins (this is no small feat). Both CCNet and CC provide first class integration to Subversion out of the box.
In either case once you have decided on a tool moving forward with open source is as simple as download and go where as commercial usually means some song and dance with you procurement dept.
Continuing to live with the product can be a very different experience between commercial and open source. The release cycle in the open source world is far more frequent than in the commercial.
Some tools already have a large Agile user base and are a driving force in the evolution of that tool. Subversion for example has a large Agile user base effecting the Subversion ecosystem. I imagine if there was a larger Agile user base for StarTeam CC’s and CCNet’s support of StarTeam would be in a much better state. When you take into account both the affect a large Agile user base has and more frequent releases of open source I am sure that you see how an open source project will respond much quicker to the needs of the Agile community than a commercial project on a slower release cycle. Let me heap on a little more: in many cases the developers on these open source project are Agile practitioners themselves where as many of the Commercial tool vendors are not practicing Agile.
