I arrived in Phoenix yesterday (Wednesday) and had no problems getting to the Arizona Golf Resort or getting checked in. There will probably be some late nights later in the conference, so I made sure to get plenty of rest before.
One of the new features this year is free wireless throughout the hotel. The connection is excellent in the conference facilities, but not so great in my room. It brings back bad memories of the dial-up days (if I get a connection at all), and there is no longer a wired option. Getting any work done over the internet is a challenge.
On the plus side, using a laptop during sessions is easy. At previous conferences, I used pen & paper to take notes in the conference binder, and after the conference, that’s where they stayed. This year, I decided to try taking notes on the laptop, with the hopes that I will get more use out of them afterwards. So far, it’s working great. The organizers have made plenty of power strips available and easily accessible.
Break it Down: Dealing with Legacy Code
I attended Alan Stevens’ pre-conference seminar. Alan is a self-proclaimed “enthusiast”, and I have to agree. He obviously has a passion for what he speaks about, and it makes for a good session. I enjoyed it.
I chose this session because I deal with legacy code every day. One thing I have to think about every time we make a change is the risk of breaking something. So, I was glad that testing was a major focus during the discussion, but skeptical at the same time. Discussions about unit testing in the past have fallen apart when you start talking about data. In my app, I don’t need to know if a coffee pot turns on and off, I need to know that the data is accurate after a process is run. “That’s not unit testing, that’s acceptance testing.” “That’s integration testing.” “Unit tests should never touch data.” Never touch the data? I’m a FoxPro programmer. It’s all about the data! Needless to say, I didn’t walk away with a good feeling about unit testing. I figured it was good for testing framework code, but not real-world business rules.
Things are clearer this time around, and we have better ideas for unit testing in FoxPro than a few years ago. Alan demonstrated testing code that adds records to a table (yes, data!) using FoxUnit. In the test setup, he created temporary cursors to house the data then ran the code to be tested. Afterwards, he ran a couple of SQL statements and verified those contained the expected values. Using temporary cursors ensures a clean set of data, but I don’t think that is an absolute necessity. It may be difficult to do if using a framework (commercial or otherwise) that expects real data, but the important thing is to make sure the data is clean and isolated from other processes that may affect the results of the test. In any case, I certainly walked away with some new ideas for how we can approach automated testing, so the session was worthwhile.
Next up is the keynote tonight. I’m looking forward to it.