I had to take several mental detours during my contribution period to go down the rabbit hole a few times, for example on Rails Active Query. I knew what I wanted to do but I needed to figure out how Rails handled these queries in order to get the result I needed. I also had to learn a lot about Capybara testing – and testing in general!
One area that has been full of stumbling blocks (and then growth!) is GIT. I’ve got a pretty good handle on the regular workflow, of push and pull and rebase. The problems happen when I do something wrong and I don’t know how to back out of it. Then I get to search google for possible answers and try them out. Usually it works. Sometimes I make a bigger mess and have to ask my mentors what to try next.
- Made a commit then wish I hadn’t? I can use either
git revert(will create a new commit undoing the changes) or
git reset --hard <HASH>(resets back to a specific commit and throws away anything after that).
- Committed to master instead of my branch? Ooops, I had to learn
- Somehow added extra commits to my branch when cherry-picking? By using
git rebase -i HEAD~8I was able to go down the list and select which commits to keep and what not to.
A Jasmine Test Failure
First stage in error debugging: google the error! Copy and paste it, see what pops up. Once in a while you’ll get lucky and the answer will be right there on the front page, someone else already solved it for you. But my error was extremely vague, “undefined is not an object” – and the same error on every test. This wasn’t just a situation of one test failed because of a change, this was all testing is completely broken.
Considering the scale of the error I wanted to double check that testing was working on my local environment at all. However, when I switched branches it gave me some errors on the command line and wouldn’t let jasmine run at all… even though I had just run them in my feature branch. This has been happening to me with some regularity, and it’s very frustrating! Sometimes I get a “grunt not found” message, which makes me confused because I use grunt all the time in that repo so how can it just disappear? I’ve learned to run
npm install just in case some dependencies were updated, that has fixed several of my issues in the past. And it did fix it this time!
First thing I tested was running
grunt jasmine in the main repo. All the tests pass, so this is a good starting point! I always like to check a known-good branch just to make sure the tests are running correctly. Once I discovered that the issue was not my feature branch at all, it was something else causing all the tests to fail! Better to learn that first rather than after spending hours searching code.
I knew there were very few changes between main and feature-branch so my next step was to compare them to see if some code had been accidentally deleted or changed when I handled the merge conflict. Google brought me to this page on Stack Overflow. I can use
git diff branch1..branch2 – but that outputs text and will be hard for me with a large file. That page also mentioned the tool Meld. This looks very useful on its own for comparing one file to another file, but how to use it with GIT? Their help files say that it can be done but didn’t give specific instructions. That page also had an answer for that:
git config --global diff.tool meld to set Meld as the default tool for git diff, and then
git diff branch1..branch2 to open it. However, one very important note here: this will open every single page in that folder, one by one. For each file there is a Y/N prompt for opening it in meld or not. I have a whole lot of files so I need a way to specify which one I want to look at! Thankfully google told me that I can easily do
git diff branch1..branch2 folder/file.js to target which one I want. Excellent! I opened it up and looked through carefully only to discover… the code looks correct, only my functions were added, there’s nothing obviously wrong.
So my next stop is to identify what code is causing the failure. I added 4 functions, so first I commented them out and ran the code – it passes. I add one back in, it fails. I leave the function there but comment out all the lines inside it, it passes. This is where I get stuck for a while because at first it seems like any code inside causes it to fail, and that doesn’t make sense. I had a forced break for a while, which I didn’t want but in the end was possibly a good thing! When stuck it can be actually really helpful to walk away and put your brain on something else for a while. Sometimes you need your brain to shift gears and get out of a stuck path – if you find yourself trying or thinking the same thing repeatedly, with no progress, then you probably need a break. When I came back I looked it over again. I had recently added a different new function that worked and passed the tests. So why did that one work and the new one didn’t? I scrolled through existing functions with an eye for what is different? And I noticed that all the other functions use
var. I used
let. I tried
var in my failing function… and it passed! Problem identified!
The final step was refactoring one of my functions because it didn’t want to run with
var. It was easy enough to find a different way to compare two values, so that was a quick fix.
I still don’t understand why jasmine caused all kinds of errors by using
let. I was only using temporary variables inside a function to do a simple task, there was no scope or re-declaration conflict. But the tests are now passing and my code was able to be pushed up for merging. And next time I’m writing code in this repo I’ll be very wary of how I declare variables!