It came down to a Capital T…

Matthew Heick geek-instructions

I had an opportunity to take a coding challenge from Dorsia with very strict rules:

  • No AI
  • No googling for info
  • Use your own code editor
  • Share your screen and video

Everything started perfectly. I was able to get the initial tests functional and things sailed very well. Then I had to write an exclusion routine and test cases for that. This is where the wall started to fall in…

I spent over 40 minutes on a problem I couldn’t diagnose, which left the remainder of the challenge with minor doubts. After getting up and walking around things magically fell into place and it came down to the letter “T” that was sabotaging me, as well as my code editor.

Approaching the problem

Firstly I kept getting a warning that I couldn’t really debug out. Without using Google this means I had to figure out how to extract the warning. My knowledge of phpunit execution and configuration didn’t really shine through so I couldn’t do something as simple as “turn on warnings”. A basic stackoverflow article gives the easiest solution ever:

public function setUp(): void
{
  # Turn on error reporting
  error_reporting(E_ALL);
}

Once this was done my error shone through like a sunbeam through a hole in the wall:

 ./dorsia test it_does_not_include_times_that_are_excluded
PHPUnit 10.5.5 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.1.27
Configuration: /app/phpunit.xml


Warning: Undefined variable $endtime in /app/src/DailyAvailability.php on line 33
W
Warning: Undefined variable $endtime in /app/src/DailyAvailability.php on line 33
F                                                                  2 / 2 (100%)

Of course my variable $endtime was actually declared as $endTime, and changing the variable to the one with the camelCase resolved all unit tests (See line#33)

Lessons to learn

Firstly I shouldn’t let something as simple as “spaces vs. tabs” irk me out. My editor should’ve been able to bulk convert, and if not I should’ve done a find-replace or a sed -i "s/\s{4}/\t/g" DailyAvailability.php. Regardless I’m certain I lost 5 minutes alone fighting around unnecessary spacing.

Secondly I should’ve used more debugging and diagnostic methods to find this problem. Turning on warnings in something as simple as my php.ini should’ve been the primary thing to do so I didn’t have to worry about calling it in the setUp().

Thirdly I should not have trusted my code editor. When I double-clicked $endTime and saw all the other instances highlighted I gained a false sense of “this is all correct where it matches” instead of scrutinized it more. This seems to be the default “trust” and action of Visual Studio but not of Sublime 3, so this lesson comes down to “pick the right tool for the right job”. To be clear: If I single-clicked the variable in Visual Studio I would’ve seen the issue, the double-clicking is what highlighted all case-insensitive matches, so “not rushing” should be a fourth lesson.

Leave a Reply