Bill Roper's Journal

Today was spent writing unit tests and fixing bugs that turned up when I ran the unit tests.

Which is, I suppose, the best reason for writing unit tests.

I have a few more unit tests to write tomorrow and then I can move on to the next project.

I am working with the code assist AI at work to try to clean up our Gradle scripts. It did a magnificent job of doing so, but managed to delete some instructions from the scripts that we use and that it didn't realize were being used. Oops.

But that's no problem. I'll tell the AI to restore the missing parts from the version that's saved in our Git repository.

If only it hadn't accidentally discarded all of the changes in one of the files when it retrieved the backup copy. Oops again.

So I have the AI remaking the changes that it discarded.

And a new appreciation for knowing when to back up code changes to defend them from the AI.

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.

We've been running the Fortify app against our source code and the section that I'm responsible for has been pretty clean for the most part. But there was one set of routines (that I did not write) that was being stubbornly difficult in being changed to avoid an unreleased resource leak. I tried one approach (a poor one, as it turned out) that just broke everything in the area, so I backed it out and went after it again.

This time, I refactored the code to avoid the particular construct that causes Fortify to lose its mind as it scans our code. Once I did that, the code still worked, which was good.

And it passed the Fortify scan that just finished.

Yay, me.

It is amazing how deleting roughly 150,000 lines of obsolete code will improve the quality of your code base.

I was talking with one of my co-workers today about how to fix some particularly intractable problems with the build, when I suddenly had the "Eureka!" moment and realized how to simplify things. Better yet, not just how to simplify things for me and my group, but for all the people in my related group of co-workers on the other side of the wall.

It's nice when something like that happens.

And so far, it's testing out ok.

Work is going well lately, although a bit disjointed as I jump between projects. But I think I managed to fix a long-standing problem with some of our cookie handling yesterday (with a lot of help from another of our folks who set up the environment and ran the actual tests). We're still testing to make sure there are no cases that defeat the new code, but it's working in all the cases we've managed to recreate so far. This makes me happy.

Home has been disjointed too, but I managed to sneak down into the basement and complete the final fades on a number of tracks. I still need to go spend some time playing with SpectraLayers, but it's been busy and is going to continue being busy for a bit.

Meanwhile, the Mets beat the Brewers tonight to win that Wild Card series, so three out of the four favorites ended up losing. This gives whole new meanings to the word "favorites". (Yes, I know the favorites lose, but they sure seem to be losing a lot in this small sample size of the last two years.)

After my mournful look at the Cardinals' season a few days ago, they have proceeded to grab two wins against the Brewers in 24 hours. This doesn't improve their position a whole lot, but it beats the alternatives.

I have a couple of things going here at home that involve filing forms. One worked, the other didn't. Now I need to figure out what it was I did wrong on the bad filing and whether or not it just cost me a noticeable chunk of money.

I have some code at work that looks like it's working, but the wrong thing is happening. So I need to find out why that's going awry. That will be tomorrow's problem at work.

Returning to the good news front, I did a load of laundry this afternoon and the dryer appeared to work correctly. This makes me happy. I am hoping to remain happy with the dryer, but at least I got to test it before the weekend.

And the trash has gone out, which is always a good thing. :)

One of my co-workers had been working on a project to fix a particular bug, but hadn't made a lot of progress on it. I suggested that I should take it over and do it while he worked on something else, since I have more experience in that neighborhood than he does. He readily agreed.

I showed him some of my interim code and he allowed as to how it was similar to the approach he had taken, but that my code was a little cleaner, because I was more willing to change some things that needed to be changed as part of the fix to knock out things that were going to be weird.

After several hours of effort yesterday and today, I suddenly realized that there was a much simpler way to fix this than the horribly invasive approach I was taking. I went into the base class for the offending group of objects, added a boolean to control an option along with an alternate constructor, and then changed one line of code in that class. And then I went to one of the derived classes and used the alternate constructor to enable the option for that class.

Everything appears to work. And I revised the unit test in the neighborhood and it agrees with me.

I'll do some more testing just to be sure, but I think this particular problem is fixed. :)

It's amazing how easy some things can be once you think about them in the right way.

I suddenly got traction on the work project this afternoon and wrote a whole bunch of code that worked.

I still need to write a lot *more* code that works, but the ball is now rolling downhill, which feels good.