I did some minor refactoring and 11 unit test broke - the Welkin Suite makes it simple to step through the code and view variables, but they can’t show me what they aren’t given – the information I need….
Source code available at https://github.com/BillKrat/LogFolderMonitor
My test is failing at line 420 but as you can see Salesforce truncates their text so I have no idea what “(28 more)” in the red box below actually means. This was going to be problematic as this information will not only help me resolve my failures, but also help in creating new unit test (values to test for). This was impacting my velocity so it was time to roll up my sleeves and crank out a little utility to rectify this.
I created a log folder monitor that will open, parse, and display only the USER_DEBUG content as the log files are created. This will aid immeasurably, particularly since I use IOC to inject values; it will help me see at a glance what implementation the factory served up for a given interface. What I am interested in right now is what the friendly message contents are for line 420 above so I can get my test to pass (without digging through my code). My logger implementation shows that I have “D”ebug statements as well as a “W”arning – it is that last warning I am interested in.
Since the console is not easy to save (other than a screenshot) I added a “o” keypress option that will open the buffered data in the default editor configured to handle .TXT files. I hit ‘o’ in the screenshot below and now can easily copy/paste what I need to fix the unit test.
At a glance I can see the culprit was from my refactoring – I decided that for logging/internal message purposes I didn’t need to keep the LCPT prefix (since all my classes have it) so I stripped them off. I have unit test that were looking for this (as was failing above) so this was a quick reminder how I can probably fix some of those 11 failing test.
To make the ApexLogMonitor easy to access I added it to “External Tools”, this way I can easily load it when I want to capture logging information.
Note: this C# console application does send all logging statements to the DEBUG output. This means you can use a utility such as DebugView to see all of the logging information as it becomes available. The DebugView utility has filtering capabilities so if you want to see only content for a given class you can do something similar to what I have below: