The LaMarr List: October 29, 2017

I’ve been on a TDD kick lately and have found some cool resources:

  • Sometimes, a difficulty about learning TDD is understanding how to construct those test functions and how they interact with the code you’re writing. Check out this tutorial to get a basic understanding of how it all works.
  • I’ve been exposed to mocha, jasmine, chai, and selenium during my first year as a developer, and here’s what I discovered: I’d start thinking about an app I wanted to make, then I’d start telling myself I should obviously do TDD with it, then I’d get overwhelmed by all the ins and outs of those testing frameworks and stay stuck in that decision-making limbo for far too long. Then I discovered tape, thanks to a mentor. Use this tutorial to see how simple tape is.
  • While you’re working through those tutorials, you’ll notice a code coverage tool called istanbul. I turned to my local Software Craftsmanship group and asked them what their preferred code coverage tool is, and the conversation turned to whether code coverage is even necessary. Here are a couple of excellent opinions to give you some food for thought:

“It’s useful to have coverage when you’re just starting out with TDD as you’ll often not realize you’ve written more code than necessary or you should have and will miss conditions. Once you can consistently do quality TDD, only writing the code required by the tests, coverage becomes less useful.”

“I tend to avoid those coverage tools as well. While I can see the allure, I think it is the wrong metric to track. Covering a function with a test does not guarantee that the function is fully tested. I prefer to track bug counts that I discover after shipping — I feel that this metric is more telling of code quality.”

So check out how istanbul works, too! Give TDD a shot, and chances are you’ll find it makes you a better developer. It’s only partly about testing your code automatically – I’d argue it’s mostly about getting into the habit of really thinking about your code before you start writing it, which saves everyone, including you, so much time in the long run. Cheers!

Remembering git

Back when I started getting into development, I read this blog post by Vaidehi Joshi. In it, she explains that one of the great benefits of technical blogging is having posts to refer to when inevitably forgetting how to do something previously learned. Unfortunately, I didn’t follow Vaidehi’s advice very well and I recently found myself needing to use git, with no recollection as to how (judge all you want, but my employer uses an in-house version control system, so I did not keep up on my git skillz). Luckily my muscle memory eventually kicked in, but it still took longer than it should have to do a simple edit and pull request – and ain’t nobody got time for that, so here you go, future self:

Step 1: Navigate to the repo you want to edit, and fork it. This copies the repo to your GitHub profile, so you can make the changes you want.

Step 2: If GitHub doesn’t take you there automatically, navigate to your profile and then to your copy of the repo. Click the clone/download button, and copy the SSH url that pops up.

Step 3: In your terminal, navigate to the directory you want to place this project into.  Type git clone, paste the copied SSH url into your terminal, and press enter. Go ahead and cd into your newly created project.

Step 4: You want your copy of the repo to have the original repo location as a remote, so you can fetch and pull from there and always have the most current code. Navigate back to the original repo location on GitHub and copy the SSH url.

Step 5: Use the command git remote add upstream followed by the URL from the original repo, then use git remote -v to check your fetch and push locations.

Step 6: Use the command git fetch upstream to get information on the upstream remote.

Step 7: You want your local master branch to point to the upstream master branch. Use the command git branch --set-upstream-to=upstream/master master (or whatever their master branch is called).

Step 8: Create a branch for whatever feature/change/bug you’re working on, using the command git checkout -b followed by what you’d like to call your branch.  Using this command will simultaneously create the branch and check it out for you – meaning, move you to that branch.

Step 9: Open up the project in your code editor and make your changes, yay!! When you’re done, you can use git status to recap what files you’ve changed and what you need to add and commit.

Step 10: Add those changed files! Use git add followed by the name of the file(s) you want to add, or git add . to add everything at once.

Step 11: After adding, you’re ready to commit the changes you’ve just staged. Use the command git commit -m, followed by your commit message enclosed in quotes.

Step 12: Now it’s time to push the changes to your local copy of the repo. Using the command git push origin pr/update-forwardjs-link means you are pushing these changes to origin, branch pr/update-forwardjs-link.

Step 13: Navigate to your copy of the repo on Github. Notice that it displays a recently pushed branch and a ‘compare & pull request’ button. Click that button.

Step 14: Select the correct base and head forks and branches. Add a comment if you need to, then select ‘create pull request.’

Step 15: You’re all done! Now it’s just a matter of waiting for your pull request to be merged/rejected/ignored. Move on to the next project in the meantime!

An image of a git repo
The repo you want to work on. Click ‘fork’ here.
An image of another git repo.
Your copy of the forked repo. Click ‘clone or download’ here.
An image of the author's terminal
All of the git commands in the terminal
An image of a new pull request
Creating a new pull request. Click the ‘compare & pull request’ button.
An image of a modified pull request
Add clarifying comments to the pull request, if needed.
An image of a finished pull request
The completed pull request. Now you wait for a maintainer to merge your work!