DEV Community: Emily Samp

Automated debugging with git bisect and rspec

Emily Samp — Thu, 14 Jan 2021 18:39:05 +0000

Debugging is hard. I mean like, really hard.

As a software engineer, I am constantly expanding my debugging tool belt in an effort to become a faster, more effective debugger. One tool that I've known about for a long time but only starting using recently is git bisect.

In this blog post, I'll explain what git bisect is, when it's useful, and how to use it to automate your debugging process with rspec.

What is git bisect?

When you discover a bug in your code, you'll often start by asking yourself, "When was this bug introduced, and how?" This is easy enough if your project doesn't have very many commits -- you can go commit by commit and check when the bug was introduced. However, the older your project is, the harder this becomes. What if the bug was introduced 100 commits ago? You can't be expected to test every single one!

This is where git bisect comes in. Git bisect is a feature in git that helps you quickly find which of your commits introduced a bug using the power of binary search.

(It's not necessary to understand how binary search works in order to use git bisect, but it's certainly interesting if you want to learn more about it!)

How it works

First, you have to find an older commit that does not have the bug. This is called a "good" commit. Then, you find a more recent commit that does have the bug. This is a "bad" commit. You know that the bug was introduced sometime between these two commits, and git bisect will help you find out when.

Git bisect then performs a binary search, choosing commits in between the ones you specified and testing whether each one is "good" or "bad" (you can automate this step, or test each commit yourself).

After a few rounds of tests, git bisect will be able to identify which commit created the bug!

If this still sounds like a lot of work, I have good news -- you can provide git bisect with an rspec test so it can automatically determine whether a commit is good or bad. This makes the process almost entirely automatic, and while you go make yourself some coffee, git can let you know which of your commits created that bug you've been hunting.

Scripted git bisect

Here are the steps you need to follow to run an automated git bisect with rspec:

Step One: Start git bisect

You can tell git to start up a bisect with the following command:

git bisect start

This puts git into "bisect mode", which means you won't be able to do things like commit changes to your code. To exit bisect mode, run git bisect reset at any time.

Step Two: Find a "good" commit

Look back in your commit history and find one that doesn't have the bug. Once you've found it, run the following command (replace a09c728 with the SHA of your commit):

git bisect good a09c728

Step Three: Find a "bad" commit

Find a more recent commit that does have the bug. Pass the commit SHA to the following command (replace b6a0692 with your commit SHA):

git bisect bad b6a0692

Step Four: Identify (or write) a failing rspec test

In order to automate the git bisect, you'll have to write a test that fails when the bug is present. You can tell git bisect to run this test on every commit, which will allow it to automatically determine if a commit is good or bad.

Here is an example rspec test in the file spec/cat_spec.rb:

describe Cat do
  describe '#speak' do
    expect(Cat.new('Proxie').speak).to eq('Meow!')
  end
end

If this test fails, you'll know that the bug is present, and thus that a commit is "bad".

Step Five: Run git bisect

Now you can run the automated git bisect with the following command:

git bisect run rspec spec/cat_spec.rb

Remember to replace spec/cat_spec.rb with the path to the test that you wrote in step four. Also remember that you can provide a line number to rspec (if you have many tests in the same file but only want to run one of them). For example, you could run:

git bisect run rspec spec/cat_spec.rb:2

Step Six: Profit

Git bisect will test a variety of commits, and it will eventually find the first bad commit, aka the commit that introduced the bug!

The output will look something like this:

> 8b3c38f8680f653f07227f0cef42e54939de448b is the first bad commit

Now you can examine that commit and figure out exactly what part of your code introduced the bug!

Step Seven: Clean up

Once you're done running git bisect, you can restore git to its normal state by running the following command:

git bisect reset

You can do this at any time during the bisect (even before you run it) to get out of "bisect mode" and get back to your normal workflows.

That's all there is to it! With a few commands and a good rspec test, you can simplify what would otherwise be a long and grueling debugging process. Git bisect has come in handy for me, and I hope it helps you out, too!

Running rspec tests with keyboard shortcuts in VS Code

Emily Samp — Wed, 09 Dec 2020 03:26:53 +0000

Running tests is an important part of the code-writing process, but typing the same commands over and over again can slow down your workflow.

Earlier this year, I was pair-programming with a new friend at the virtual Ruby For Good conference, and he showed me a trick that blew my mind -- he used keyboard shortcuts for running rspec tests! He even had a shortcut that only ran the test he was currently working on.

I can't believe this hadn't occurred to me sooner.

I recently started a new job, so I decided to set up similar keyboard shortcuts in VS Code. Here's how I did it:

Create User Tasks

Tasks are a feature in VS Code that allow you to automate common workflows, like linting, building, or even testing! As with most features in VS Code, it is possible to build and customize your own tasks.

Open the "User Tasks" settings

Open the "all commands" menu by pressing Cmd + Shift + P
Type "Open User Tasks," and select the menu item that comes up
This should open a file called tasks.json, which should have the following format:

{
  "version": "2.0.0",
  "tasks": [ ... ] // <-- There'll be some stuff in this array
}

Add a new task to your User Tasks

Copy and paste the following code into the tasks array in your tasks.json:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "(ruby) run all tests",
      "type": "shell",
      "command": "bundle exec rspec",
      "presentation": {
        "echo": true,
        "reveal": "always",
        "focus": true,
      }
    },
  ]
}

This task has the following fields:

label: The name of the task
type: Telling VS Code to run this task as a shell command
command: The command to run in the shell (in this case, run all the rspec tests in this project)
presentation: This is a list of options determining how the output of the task is displayed. Read more about those in the VS Code Tasks Documentation.

Add the rest of your tasks to your User Tasks

In the previous step, you added one task, but you can add as many as you want! I have three tasks:

bundle exec rspec: Run all the rspec tests in the project
bundle exec rspec <filename>: Run all the tests in a file
bundle exec rspec <filename>:<line number>: Run the test at a specific line number

Here's what my tasks.json file looks like:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "(ruby) run all tests",
      "type": "shell",
      "command": "bundle exec rspec",
      "presentation": {
        "echo": true,
        "reveal": "always",
        "focus": true,
      }
    },
    {
      "label": "(ruby) run tests",
      "type": "shell",
      "command": "bundle exec rspec ${relativeFile}",
      "presentation": {
        "echo": true,
        "reveal": "always",
        "focus": true,
      }
    },
    {
      "label": "(ruby) run current test",
      "type": "shell",
      "command": "bundle exec rspec ${relativeFile}:${lineNumber}",
      "presentation": {
        "echo": true,
        "reveal": "always",
        "focus": true,
      }
    },
  ]
}

You'll notice that these two new commands use the variables relativeFile and lineNumber. These will be replaced with the relative path to the current open file and the line number where your cursor is located.

Using these variables allows you to run all the tests in the file you currently have open, or even the specific test that you currently have your cursor on!

You can read more about these variables in VS Code's Variable Reference.

Add keyboard shortcuts

Once you've added new User Tasks, you can create custom shortcuts to run them whenever you want.

Open the Keyboard Shortcuts settings

Open the "all commands" menu by pressing Cmd + Shift + P
Type "Open Keyboard Shortcuts (JSON)," and select the menu item that comes up
This should open a file called keybindings.json

Create new shortcuts

Here's what my keybindings.json file looks like:

[
  {
    "key": "cmd+shift+0",
    "command": "workbench.action.tasks.runTask",
    "args": "(ruby) run all tests"
  },
  {
    "key": "cmd+shift+9",
    "command": "workbench.action.tasks.runTask",
    "args": "(ruby) run tests"
  },
  {
    "key": "cmd+shift+8",
    "command": "workbench.action.tasks.runTask",
    "args": "(ruby) run current test"
  }
]

For each keyboard shortcut, the key option determines which keys you have to press to activate the shortcut. I've opted for Cmd + Shift + 0, Cmd + Shift + 9, and Cmd + Shift + 8, but you should pick key combinations that feel comfortable to you and don't interfere with any existing keyboard shortcuts you like to use.

Use the args option to specify which task gets run with each shortcut. Make sure this value matches the label you used when you created the User Tasks.

Profit

Now, when you use one of your custom shortcuts, VS Code will open a new terminal tab and run your tests for you! No more typing out a long command or remembering exactly which line number your test is on.

This has saved me so much time in the past couple weeks, and I hope it saves you time, too!

Three Lessons from RubyConf

Emily Samp — Thu, 28 Nov 2019 02:07:23 +0000

This year, I had the good fortune of attending RubyConf along with 800 awesome Rubyists. As someone who is still fairly new to industry, this was my first major language conference, and I didn't quite know what to expect; I thought I might learn a few new things about the Ruby language and meet some new people. Needless to say, I was not quite prepared for what I was about to experience.

Though I did learn a lot about code, I learned so much more about community, collaboration, and ethics. The people I met thought not just about the software they wrote, but the context in which they wrote it. I had conversations with total strangers about engineering culture and how to best encourage underrepresented developers. I ended each day of the conference feeling giddy -- I couldn't wait to tell my friends all of the amazing things I'd learned that day.

In this article, I want to share the three most important lessons I learned at RubyConf. I've used Ruby boolean expressions as section titles because Ruby is great, and I am a nerd. (And yes, all of the titles evaluate to true.)

Lesson one: code == community

The first talk of the conference was a keynote by Yukihiro Matsumoto, (aka Matz), the creator of the Ruby language. Though Matz spent much of his talk focused on the new features being introduced in Ruby 2.7 and Ruby 3.0, he opened his keynote, and the conference, by highlighting what makes Ruby great. In his own words: "Ruby creates programming joy."

Ruby is a language created to be readable. It is created to make people enjoy programming, which will boost their productivity and encourage them to develop tools and frameworks around it. Ruby is a language fueled by the people who love it.

Of course, this means that Ruby can't survive without an active community.

It's no secret that the Ruby language has been losing popularity over the past few years, especially as Python becomes increasingly popular for scripting and data science work. This fact is not lost on Matz. He emphasized that the Ruby community needs to keep growing, but that he and the other Ruby language maintainers can't expect loyalty for free. They plan to roll out features that have been requested by the community, such as pattern matching, improved GC, a better repl, an improved concurrency model, and static typing.

The first lesson I learned from RubyConf is that community is the essence of code. When you create an open-source library, you're not just releasing streams of binary into the void. You're getting someone on the other side of the world that much closer to building their dream project. You're teaching a new engineer best practices. You're unblocking the way so that other people can build on top of your work.

That leads me to my next lesson.

Lesson two: (idea + collaboration) > idea

After Matz's keynote, I attended a session called "Thomas Edison vs. Three Teslas in a Trenchcoat," presented by Coraline Ada Ehmke. Though her talk was primarily about choosing when to adopt new technologies, Ehmke said something that really struck me (and I'm going to paraphrase here because I didn't write down the exact quote during the talk): ideas flourish within intense intellectual relationships.

Software engineers love to spread the myth of the lone genius -- they imagine the ideal engineer as a man (usually) so brilliant that he doesn't need to collaborate with anyone else. In software engineering, this could manifest as the senior engineer who refuses to document his code or deploys without code review -- you know, your typical "10x engineer." Much has been written on the topic of the "lone genius," so I'll point you to one Medium article that I particularly like).

In her talk, Ehmke gave the example of one of the most famous "lone geniuses" in history: Nikola Tesla. Tesla was notorious for being an eccentric loner, but Ehmke emphasized that he could not have revolutionized the field of electrical engineering by himself. In fact, it was his rivalry with Thomas Edison that forced him to become smarter and more creative, to make his ideas bullet-proof. Though we often point to Tesla as an example of the "lone genius" archetype, he was anything but.

At RubyConf, I attended countless sessions that stressed the importance of collaboration. On day one, the closing keynote was a talk called "Collective Problem Solving in Music, Science, Art, and Software" by Jessica Kerr. In her talk, Kerr emphasized that software engineering is the product of the relationships between people and the software they build. Whether or not an engineering team is successful depends on people on the team having accurate mental models of their code. As software systems grow increasingly large and complex, it is impossible to trust one person to keep a model of an entire system in their head. Our success as engineers depends entirely on our ability to transfer our mental models, especially (ESPECIALLY!) to people who think differently than we do.

Kerr put it perfectly when she said, “Ideas become bigger when you share them."

Lesson three: (code - context).empty?

It's hard to pick my favorite part of RubyConf, but if I had to choose, I would say it was the Birds of a Feather (BoF) sessions. If you're unfamiliar with that term (as I was until literally the day before the conference), a BoF is an informal session where people can get together to discuss a topic of shared interest. At RubyConf, I attended two BoFs.

The first was a session on Ethical Open Source led by Coraline Ehmke, whose talk I had previously attended. She recently created the Hippocratic License, an open source software license that prohibits people and organizations from using software to commit human rights violations. In her session, we talked about ethical open source licenses, why they're necessary, and what we can do as developers to promote ethical development practices.

The second BoF I attended was about Ruby For Good, an organization that puts on conferences where Ruby developers build projects to help non-profits. During this session, I spoke to some of the Ruby for Good organizers and participants about about the projects they'd seen, including a diaper bank inventory app and a data tracking system for abalone conservancy. They had a pretty easy time recruiting me, and I hope to start contributing a Ruby For Good project in the next couple weeks!

The lesson I learned from these Birds of a Feather sessions was two-fold: not only do we have an obligation to create tech that makes the world a better place, but we also have to ensure that our work isn't used to cause harm.

Sandi Metz, author of Practical Object-Oriented Design in Ruby, brought this message home in the final keynote of the conference. Metz began her talk, titled "Lucky You," by explaining the difference between lucky people and unlucky people. According to research done on the subject, people get lucky because they expect to be lucky. Of course, that begs the question: who expects to be lucky? Throughout her talk, Metz demonstrated that where one grows up, along with one's race, gender, and income level, often predict how successful (lucky) they will be. This isn't because certain groups of people don't work as hard or aren't as smart; it's because of systemic inequalities that date back generations.

In recent years, big tech has done a lot to widen the inequality gap. We live in an economic system designed such that the tech-elite can hoard wealth while many people can't even afford to pay their medical bills. This is wrong, and those of us who have the privilege to work in tech are responsible for making sure it gets better.

This was my biggest takeaway from the conference: code cannot be separated from the context in which it is written. The software we build has real-life consequences. It can give a platform to the voiceless or expose people to bullying and abuse. It can spread information faster than ever before or foster communities riled by hatred. It can be used to open up the world or tear people from their homes and families.

We choose what our technology does, and those choices matter.

Metz ended her keynote with this call to action:

Decide what social problem pisses you off most, and then pursue a solution that is public, democratic, universal, and institutional.

~ Anand Giridharadas

My hope is, that now and throughout my life, this is what I choose to do.

I went to RubyConf to learn how to be a better coder, and I did, but not in the way I expected. I learned about the importance of software communities. I learned that ideas are best when shared. And finally, I learned that our code is only as good as the context in which it is written.

There is still a lot of change that needs to happen in the tech world. However, I came away from this conference with a fresh perspective and a renewed commitment to work towards the things that drew me to tech in the first place: spreading ideas, creating things that matter, and empowering others. My hope is that, by writing this blog post, I have encouraged you to do the same.

And who knows. Maybe we'll see each other in Houston next year.

Addendum

In a blog post partially about Nikola Tesla, I would be remiss not to include my favorite Tesla-related thing from the internet. This is taken this post by Tumblr user salamandertoast. Here you go: