One of the things I’ve been finding most challenging as I develop PopTrayU is how to test and debug issues with emails. There’s no easy way to select an arbitrary email and paste in it’s raw headers to test the email.
Or just in general, situations like this: a user reports some bizarre error message that doesn’t make sense and is poorly worded about how dollar sign underscore isn’t an integer…they got this email from ebay.de that caused the error message. A little searching the code and google reveals the error message is probably caused by trying to convert a string to a number. Well, ok, so have a good suspicion of a couple places that might do this, such as where it’s converting dates around…but I need an email with the bad headers to cause this behavior… no easy way in. This bug has been around for some time (since before I started messing with the code), and it seems, in my opinion, that if it’s going to give an error message it should at least make sense, eg: “this email message is corrupt” and it should try to display the bad data as best it can excepting the corrupted header if it can’t be salvaged.
On the one hand, I could modify that code to try to fix the bug, but without creating a repeatable test-case, I have no way of verifying the fix actually fixes anything and isn’t just an incorrect stab in the dark.
As I think about how could I make the code more testable, I keep coming back to the need to break the code up into modular pieces, rather than a 7000+ line uMain.pas file. If I could break apart the pieces where it’s doing the message processing from the UI and input data source, I could make a second unit test project that fakes the input data and does something different with the output rather than display it on the UI.
So, now that I fixed the internationalization code so all my new labels are translatable (unrelated, but needed to be done), I think some refactoring will be my next sub-project…see if I can break down the mammoth main file into more bite-size chewable testable sections.