Anthony Panozzo's Blog

It seems like the more I read about different development models, the more I see overlap between the different paradigms. Even if you aren't using one of them for a given project, just knowing about all of them makes your code better because you realize how to make your code more testable.

One thing that has piqued my interest of late is theories in JUnit 4.4+.

Overview

In JUnit, the still experimental theory functionality is derived from the open-source Popper project. The name comes from Karl Popper's work on the philosophy of science. He was a major proponent of saying that something isn't scientific unless it is falsifiable, and that theories cannot be proven correct, merely shown to have exceptions. If someone can provide an exception, it means that the theory does not match all of our observations. Theories are models of the world, so while a model may not be correct, it can still be useful.

So what are theories in software good for? When using test-driven development, the tests serve as a form of code documentation. However, there are certain properties of code that are known or assumed by the developers that are difficult to codify as simple tests. Theories provide a simple and expressive means for at least the following cases:

• identities and data conversion
• globally disallowed behavior
• data that should be preserved after performing an operation or set of operations

For example, you might have a theory that data that is serialized into XML and then unserialized should always result in the original object. This seems to make sense, but it might be time-consuming or error-prone to specify all of the different tests that you have to consider. A single theory can codify this assumption.

Oh man, I was so excited when I downloaded the newest version of Google Chrome in Chrome and it started automatically installing. Google is installing the update for me automatically like a real browser! I don't have to do it myself, the browser just knows that I want to update it. I messed around with Chrome a long time ago, but was put off by a lack of maturity.

Then, I got this helpful error message:

Last Friday I attended the full-day Indiana Workshops on Software Testing conference with Jen, Howard, Beth, Jeremy and about ten other people. This session was very helpful in understanding my personal knowledge of testing, learning new skills and about previously unknown technologies, and meeting people in the testing community in Indianapolis. I presented second, and discussed my experiences with Test-Driven Development on a recent Rails project that I worked on.

The first experience report probably had the most relevance to things that I have directly worked with. In the production Rails project that I worked on, we used Selenium for automated integration testing as verification of the development process. Dave Christiansen covered using Selenium to do automated integration testing on a Rails app. However, what was noteworthy to me about the approach that he took was that instead of writing and executing these tests only in the test phase of the development process, they were written and executed throughout the development lifecycle. He wrote a wrapper to generate RSpec tests from the Selenium IDE, refactored to DRY up the code, and then had the team write their own integration tests as they were developing. Since the tests were written in RSpec, they would actually be run whenever code was checked in (continuous integration.) After awhile, they built up enough helpers to stop really using Selenium at all except for replicating bugs.

If you're seeing this post, then my nefarious plan worked.

I had the idea of having a personal blog external to SEP after seeing that the posts and comments could not be seen by others outside of the company. Essentially it was like emailing everyone internally. More importantly, no cross-pollination with the community could happen either. It seemed like the overall value could be improved by taking a little more effort to put the ideas out there. I talked with a few people about their blogging habits and practices, and determined that this could work.

Here are my notes from a Microsoft ArcReady seminar I went to in the middle of May. I went because I wanted to know more about building web applications that scale to many users. I definitely learned the basics of this, and found some references to other work as well.

At least one interesting thing that I learned was ProtoXAML, which is a way to take prototypes and make them seem a bit more flawed so that customers are more likely to give you good feedback. It was interesting to see this perspective, and might be helpful with some client interactions we have.