Ever Changing, Yet Always Me

We have a lot of unit tests that are running fine in the JDeveloper environment that do *not* run in the build environment. This has been a source of a lot of frustration for my co-worker who has been trying to solve the problem so I set out to dig into it today.

The first thing I did was get him to confirm that the build wasn't doing anything acutely stupid, since there are multiple separate build steps that actually rely on each other in a loop. This is an annoying problem (and not correctable in any reasonable way), but you can check through the loop by hand and he did so and determined that my first guess was wrong. Oh, well.

Ok. If you can't use the debugger because the failures are in the Gradle build, you can always go old school. It was time to start modifying the code and putting in debugging statements to drop data to the console. And so I did.

I got the stack trace for the mysterious exception that was shutting down a large number of the failing unit tests and went to stare at the source. Eventually I realized that *someone* (and it may well have been me) had written a particularly stupid little class loader that will load one class in one environment and a different class in another environment -- say, for instance, when you are running your unit test in the build environment. And when the alternate class it is trying to load isn't in the build environment either *and* is the completely wrong class to be loading, well, you've hit the jackpot.

I quickly wrote the missing class to implement the interface, causing every method to throw a NotImplementedException. This was the right choice in this case, because the interface described how to talk to the database and none of the database code is present in this particular part of the build, so you can't get it to run the unit test. And now my Class Not Found exception turned into a NotImplementedException -- and I was already dropping the stack trace out so that I could see that I was attempting to load the access record.

Huh. Now the model that I was working with in this set of unit tests was one that I had initialized by hand and it normally works fine -- until you try loading a feature that requires an access record, which it then tries to load from the database, which is not present. I wrote a class to initialize the access record and tucked it into the model initialization routine and almost *everything* started running correctly.

Happy dance! Except there were still a few (like four) unit tests that were failing for some unknown reason. One of these was working with a tiny grid that I'd initialized in my tiny model. Other things were working correctly with the grid, so why wasn't this one?

I finally wrote a routine to dump the tiny grid to the console and discovered that none of the values that I'd tried to change in the grid were actually getting stored -- with the result that the unit test didn't find the expected values and promptly failed. I managed to find where the error codes were stored and they were all the same code, so I found all of the places that could give me that error code and stuck a debugging statement in, which eventually led me to the point of failure.

I was getting an exception when I tried to parse the input value of "160.1". The exception claimed that the character in the zero position was failing, but when I looked at the exception, I realized that I had cleverly just passed back a zero instead of looking to see which character in the string was the problem. Well, *that's* easily fixed. It's the character in the *third* position. It's the decimal point. Why do I believe that a decimal point is an illegal character? Could it have something to do with localization and assembling the set of valid characters based on the locale's decimal separator?

Yes. Yes, it could.

Gradle not only runs the unit tests in multiple threads, but it *reuses* threads. The LocaleTest switched a thread to the French locale, where the decimal separator is a comma, and didn't switch it back. It does now.

And suddenly, the rest of the unit tests started working. Well, except for one test where the correct files aren't present in the build environment. I commented that particular test back out as a problem for another day.

And then I pulled out all of the spurious debugging code that I'd put in. I kept the grid printing code around though.

You never can tell when you're going to need it. :)

Or to quote one of my songs:

"I want to be old. I want to be wise.
I want to be just a little bit smarter than all those younger guys."

Amazing what you can learn from experience.

I had my follow up appointment with the opthalmologist today. Everything appears to be progressing well and Z'hadum (my name for the giant floater) is getting smaller and thinner as it is slowly getting absorbed. I've got another follow up scheduled in two months, by which time I hope there is a whole lot less of Z'hadum hanging around.

The problem, of course, is that as the floater gets smaller, it becomes lighter and more mobile, so it spends more time drifting across my field of view. But it's getting better and that's what counts.

The new heatsink for Julie's computer arrived today (a day earlier than forecast, probably because the part was already in the Chicago area), so I installed it tonight around dinner. This was a little bit of a challenge, because the design has changed a bit with the newer model of the heatsink, but I eventually interpreted all of the pictures correctly and got it tucked into place.

The computer is now back in its place in the basement and substantially quieter than it was with the stock heatsink from Intel. :)

Julie got to observe the process, because it is good to learn how to fix your own computer.

We apparently got around four inches of snow, which Julie has shoveled off the driveway. The cold means that the salt that is hitting the roads is not nearly as effective as you might hope, so things are very slick around here. This was slightly important when I ran out for lunch, but got to be a whole lot more important later in the day.

Julie noticed that her computer was misbehaving again and asked if I could blow the dust out of it. Since Gretchen gifted me with a fine blower fan for just this purpose, I said I'd be happy to if she brought it upstairs, but then it decided to shut down from overheating before then.

Ok. There was some initial confusion about what fan was having the problem before Julie made it clear that the CPU's heatsink fan had given up the ghost. Oh. I had replacement case fans that I'd picked up at an earlier date, but I don't have a replacement for a CPU heatsink. If we were having good weather, I'd have just shot down to Micro Center to pick up a replacement, but I was positively not making this trip on these roads. And unfortunately, the replacement I ordered from Amazon won't be here until Tuesday, assuming that there are no weather delays.

But we have a computer in the dining room too and everything Julie wanted to be doing was on line, so we were able to get her set up on that machine and she is happily tapping away. Well, except for the fact that there's a noticeable hum when her headphones are plugged into the speakers, because she's listening at a very low volume. There's nothing trivial to be done about that, so here we are. (I checked obvious things with no luck.)

Calvin the Dog picked today to have two separate "accidents" in the house; one of each kind. This was especially annoying, because accident number two (of number two) was right after we had let him back in. *grumble*

On the better news front, the Seahawks beat the Rams. :)