I go over this advice with all the team members of ShakaCode:
- Don’t get stuck for more than 10 min, ever, if you can avoid it.
- Read any error messages carefully in your console or logs.
- If you are stuck, you are “yak shaving”. See the next set of rules to recover!
Avoiding Yak Shaving
Follow these steps, roughly in order.
- Did you follow step 2 above and read the error message carefully. This can circumvent putting you in the yak shaving state.
- Be sure your problem is reproducible. Sometimes the fix is to
kill -9processes that did not get cleaned up when you did a Ctrl-C in the console. I use this pgkk function many times a day.
- Google for the answer. Maybe ask other team members what to Google for. Try several variations of what you’re Googling for. If really nothing comes up for your specific error, it’s almost always going to be your fault with some incorrect code.
- Read error messages and logs CAREFULLY. Be sure you didn’t miss any places that your code is logging. For example, when running Rails tests, also check log/test.log. Clearing the screen when tailing the log (cmd-k for iterm2) right before starting a test. I often clear both the console where running the test, as well as the log file. Consider changing the loglevel to
- If you’re debugging rspec tests, and the stack trace doesn’t make sense as to the cause of the error, then you want to run
rspec -b. The
-boption is critical as it will give you a full backtrace.
- Dig into source code. Add
debugger(JS) to areas of interest. Yes, you can modify the ruby gems and node packages! This really helps.
- Build a simple prototype. Take baby steps.
- Ask team members, but respect their time. Then again, when you’re really stuck, you’re hurting the team if you stay stuck too long!
When you do solve the problem, and it can be of general interest, please post what you learned, such as to this forum!
Debugging Rails Test Failures Caused by Other Tests
If you’re debugging the nasty issue of “my Rails tests fail when run in batch” but not individually, then you have to narrow down the “cause of failure test”, and the “test that passes alone, but breaks in batch”. This is not easy. You want to follow these steps:
- Clear the logs:
- Run the suite that makes a singly passing test fail.
- Study the logs up to the point of the singly passing test failing. Don’t worry about anything afterwards in the logs. Look for the words “exception” and “error” in the logs. Use a lightweight viewer, such as
lessthat can handle large files. If you don’t find good info, change the loglevel to
- Try to create smaller set of test files that still cause the singly passing test to fail.
- Iterate on these steps. And read the logs very carefully.
In general, the logs will always show you the point of failure, UNLESS some evil programmer decided that swallowing exceptions was a good idea. Usually, stepping through the code in
pry or the Chrome debugger will find that, but not without great effort.