solipse (Eclipse on Solaris)

Congratulations to Tim Myer and Hugo Garcia for their valiant efforts getting Eclipse running on Solaris codename solipse!

GWT Testing Blog Posts

One of the smartest and likable fellows I know, Daniel Wellman, is being publish for his work with GWT(Google Web Toolkit). It all started with this blog post:
http://blog.danielwellman.com/2008/06/strategies-for-testing-gwt-widgets-and-view-components.html
Enjoy!!!

I've switched

I took my family on a shopping spree this weekend. Our last stop was at Best Buy where my wife gave me a choice between:

and

Guess what I picked?!?

How Ruby made me into a better Java developer

Like most programmers, I have had the pleasure of being exposed to multiple programming languages and frameworks. In some way all of these experiences have influenced the way I think about testing and challenging my beliefs about "good" design. After reading the Pragmatic Programmer for the second time, it occurred to me that this is happening because I...

Invest Regularly in Your Knowledge Portfolio
Make learning a habit. [Thomas and Hunt]

I started my career as an ASP classic VB 6 developer. Learning Java taught me that I should really think more like an OO programmer. It also exposed me to design patterns and forced me to realize that the code I was produced was actually a big mess. Java changed the way I was doing things. I started to use patterns like; proxies; late binding; interfaces; and factories. This greatly improved my ability to test production code and helped me reduce the outrages scriptlet code found in the web pages I was working on.
Then came C#. The transition from Java was not so difficult but I did learn more about delegates, data binding, event driven programming, as well as presentation patterns that were not MVC. It did not seem to make quite as much of an impact on the way I wrote Java apps. I did however find myself asking questions about how useful EJBs where and whether or not a DTO made any sense! I also longed for a "using(closableResource)" so that I would not have to write so many try/catch statements. MbUnit also really impacted the way I thought about testing and how refactoring test code was just as important as production code.
Then there are more complex things like SOA based applications using SOAP/WSDL and how it made me think about designing reusable components using better interfaces. I also learned a lot about how really useful adapters, bridges, and facades mitigate integration nightmares.
Now I find myself reflecting on how Rails influenced the way I approach Java Web applications and how it changed the way I think! So much so that the next few posts are going to be about:

• Component/Integration Testing
• Unit/Micro Testing
• Test Driving UI
• Using conventions in my configuration
• Simplifying the way I use Hibernate
• Using composite views with partials
• Meta programming and annotations
• Action mappings
• Simplifying Models

I hope that you find the topics interesting and please do not be put off because I am writing about RoR. I am not one of those people who now hates Java and believes that Ruby is better, I am just a believer in learning and growing.

HELP! My project has no tests!

There are a few ways that you can introduce tests if your team is in this situation.

Thorough Manual Verification!

• Hire, outsource, or distribute the work of manual functional testers. Make them run a full suite of regression tests with every build.

Automate It… ALL OF IT!

• Convert your current manual functional or exploratory tests scripts to automated “end-to-end” tests.
• Write "end-to-end" system integration tests that "prove" everything really works. For example, write some tests that somehow verify the jobs extract data from a mainframe and then import them to your RDBMS.
• Install code coverage tools and run reports. Get all of the developers to write tests until they see 80-100% coverage!

The Pragmatic Approach…

• Slowly add automated tests which, run with every build of your application.
• Write focused automated tests to help identify the root cause of bugs that are currently in production.
• Identify the areas of your application that “break” the most and prioritize them testing/fixing them as features.
• Write focused automated characterization tests for the code/features you are going to change.
• Write focused automated tests only for the code/features you are working on.
• Use manual exploratory testing to validate that the features were implemented correctly.

Results
The problem with the thorough manual approach is that it is expensive to coordinate and execute. In addition to that, development slows down so revenue generating features don’t make it production fast enough to help pay the salaries of all of those testers.

Then there is the thorough automated approach. Like its manual counterpart, it is a tedious exercise, which often discourages developers from writing “good” tests that actually provide any value to the product owners. It is also an extremely difficult feat to accomplish because these systems were not built to be testable in the first place. The end result is often a collection of “tests” that do not really verifying if the system is doing the right thing in order to increase statistics.

There is little return on investment for features that are either; stable and running in production with no reported bugs; or not used enough for anyone to notice if any bugs exist! That’s why I recommend the pragmatic approach. Keep your tests focused and small, don’t feel obligated to write automate tests for every single part of your application; some things just don’t break once you’ve performed exploratory tests.

Not only does it allow you to start providing coverage for your application, but it also immediately improves your ability to provide working features. This will not only increase your teams’ confidence and self worth, but you’ll be making money for your product owners in the process!

I'm angry

I recently received some feedback from a few of my esteemed coworkers. They said that my posts are interesting because they seem to be filled with quite a bit of anger. They also gave me some practical advice like, “run your posts through grammar checkers so that you don’t sound like a tool”.

After reflecting on the former statement, I realized that I am filled with anger! Like most of my fellow XPers, I’ve had to endure years of suffering under a regime of SDLC monkeys! Now this pain is manifesting itself as wrath and I have vowed to rid the world of these wankers one by one.

From this day forward, I bring you Angry XP!

Expressing Intent

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -Martin Fowler et al, Refactoring: Improving the Design of Existing Code, 1999

I remember when I first started programming, I spent most of my time trying to understand what "the code" was doing. If you were anywhere near my cube, you'd might catch me saying things like, "what are you doing? why are you doing that? does anyone actually use you?"

The problem is that code doesn't "talk"! It doesn't tell you the reason for its existence. It merely exists. Some might use comments to help communicate intent, but that seems more like one is trying to apply deodorant to keep things fresh. The problem is that most antiperspirants or deodorant usually stop working after 24 hours. Eventually the comments are unable to mask the smell that bad code produces.

Here is an example of my favorite comment of all time:

//this variable is set to true for TeamTrac BUG #64322
boolean bool = false;

Wouldn't if be nice if you could simply look at code an almost instantly know what it wanted to do? Like most experienced programmers, I have a "feeling" for what I consider to be "good" code. One of the qualities I look for is "intent", because my experience tells me that doing so eliminates waste during development time.

The next time you are tempted to write a comment about what your code is trying to do, make it more explicit. This I doesn't mean that you have provide every detail in your method name either, just tell me what the "intent" is. For example:
updateProfileFeilds(firstName, lastName, userName, password)
works as good as
updateFirstNameLastNameUserNamePassword(firstName, lastName, userName, password).

I encourage you to refactor your code so that it expresses the intent. Instead of simply applying deodorant please keep your code clean! You will thank me six months from now when you won't have interrogate your own code, because you'll actually understand what its doing at a glance!

XP Practice - Quarterly Releases (a.k.a. Small Releases)

My experience of working on projects where our teams rely on manual regression testing in order to "certifying" or "sign off" on a release candidates. Depending on the size and complexity of your product, it may take weeks or even months for your team to perform these tests manually.

When the release candidate is ready for production, your team will most likely have to manually or a partially automated deployment process. It may require coordination between multiple groups within your organization like a DBA, IT staff, and release engineers. Since they do not write any of the code or produce the artifacts, they are unable to deal with any failures that occur during the release process.

The longer the intervals where your team performs an activity, the less likely they are to fix any process bottlenecks. The beauty of extreme programming is that it uses "continuous process flows so that problems rise to the surface". Take for example the practice of quarterly releases, forcing the team to commit to having a maximum of 3 months between releases exposes bottlenecks in your teams software process.

Ideally you want your product to be releasable on a daily basis and your team should be able to perform a deployment upon each and every commit to the source repository but that takes of lot of discipline, automation, "correctness", and changes in attitude. Realistically, you will have to make little changes to help enable your team to practice "small releases". Here are a few to start with:

• Work with your product owner so that the next release of your product occurs withing the next 3 months. Get them to work with you to build enough slack into a release
• Work with your production team to automate all aspects of your release process
• Write component, unit, and acceptance tests and make them part of your build process
• Train your BA and QA team to use exploratory testing techniques instead of performing full fledged regression testing
• Automate your smoke tests with tools

Good luck and happy releasing!