floating point

I wrote three papers at the end of last semester. The first was the proposal for my master’s thesis. My project is inspired by David Saff’s test factoring project. It can be relatively easy to write a few top-level system tests for an application, whereas it can be slow and tedious to write a complete suite of unit tests which exercise the entire program. The concept behind test factoring is that by dynamically observing the execution of a system test, we can automatically generate a large number of unit tests which drive individual objects in the same way that the entire test suite did.

The main focus of David Saff’s project was efficiency: a very slow system test can be run much quicker if the code in only a small number of classes is executed, and the rest of the world is replaced by “mocks”. His project executed the program in a specialized runtime environment which read from a transcript of the system test and simulated method calls which reached outside of the tested classes by just returning whatever they did during the system test.

That project is quite interesting. However, my focus in test generation is less on efficiency of running tests and more in ease of creating and modifying tests. Often, you may find yourself needing to change a test you wrote to be more lenient: to allow a return value to take on more values, or to allow two events to occur in a different order, for example. The ability to do this is even more important for automatically generated tests, which never had the benefit of a human writer and may be very brittle. So, my project (which I am calling @amock@) has the same general idea as test factoring, but its output is standard Java code. The generated tests must be legible and comprehensible by developers; developers much be able to relax and otherwise tweak the generated tests. In order to implement “mocking out the world”, I am using jMock, a Java mock-object library. (Yes, I do realize that the mock objects folks prefer to think of mock objects as a design aide and not a post facto testing tool; perhaps this will lead to the generated tests not being very good for most programs. We will see.)

My goal is to implement @amock@, write my thesis, take two classes, and TA another one this semester; I’ll move to San Francisco and start my new job after that. Since this is a pretty heavy load, there’s a reasonable chance it’ll take me the summer to finish up the thesis and I’ll have to wait on the job; let’s hope that doesn’t happen.

My other two papers were group projects for my classes last term. I’d describe them both as interesting projects which didn’t pan out as conclusively as we’d hoped; however, I’m still pretty happy with both of them. For my databases class, I looked into the best database structures for implementing oh-so-trendy-Web-2.0 tagging queries, working with Richard Tibbetts and Chris Laas. For advanced algorithms, Natan Cliffer and I explored what we called packing dual problems of machine scheduling problems: problems that generalize the NP-complete bin packing problem in the same way that machine scheduling problems are generalized. I think our classification is an interesting idea, but unfortunately we didn’t prove any non-trivial results about specific subproblems.