DEV Community: Tracy Lum

How to Convince Yourself to Use Test-Driven Development

Tracy Lum — Sat, 04 Apr 2020 18:36:34 +0000

There comes a time in every developer's career when they must ask themselves if they want to write a test before they write the actual code.

That time came for me probably around two years ago, and now that I (pretty) consistently practice test-driven development, or TDD, I've (almost) never looked back.

Prior to writing tests, as a new developer, I coded with abandon, furiously typing and stuffing code into places it didn't really belong just to make a feature work. I thought that tests held me back from making real progress. They slowed me down and prevented me from shipping as fast as possible.

In reality, there existed the minor problem that I didn't really know how to write tests, and learning an entirely new skill under a tight deadline didn't seem feasible. So I didn't write tests for probably the entire first year of my career as a professional developer. But had I invested some time in learning testing, I would have saved myself a lot of hassle and heartache.

Some people make the case that writing tests is a waste of time, and in some startup environments, where cash is strapped and time is running out to deliver a viable product, that may be true. The best-tested code that doesn't deliver value is indeed useless to the business.

But for the rest of us, who work at slightly more stable companies with growing businesses and feature sets, tests are actually an invaluable part of the feature development cycle.

I can preach all day about the benefits of testing—how it documents working code, how it communicates intent to your team, how it saves you from yourself, how it allows you to refactor safely, how it sets juniors and seniors apart—but you probably won't believe me until you experience the magic of testing for yourself.

If you still need convincing that TDD, or really writing any tests, is essential to your workflow, read on for tips on how to convince yourself to practice TDD.

Feel the pain

I'm not joking about this one. To see the benefits of testing, all you need to do is step into a particularly gnarly codebase, change one line of spaghetti code, then watch unexpected bugs appear from out of nowhere. To truly understand why testing is beneficial, you do actually need to mess up for yourself a few times. No amount of anyone preaching to you that "testing is good" will convince you otherwise. And when you're tired of feeling the pain, you'll be able to explore some solutions.

Learn about testing and refactoring

I (unfortunately) am still no expert on testing, but I still get by with TDD. A few books helped me change my mind on the necessity of testing and specifically how writing tests for how certain classes or components can allow you to refactor safely your existing code. 99 Bottles by Sandi Metz and Katrina Owen and Working Effectively with Legacy Code by Michael C. Feathers are two books that I recommend to change your mind. You can also learn about design patterns if you really want to take your coding abilities to the next level.

Continue working in an ever-changing codebase

Even intellectually understanding why testing is beneficial won't alone change your mind about testing. As you continue to work in an ever-changing codebase, you may come to realize that you're making a lot of changes and praying. Hope does not inspire a lot of confidence in software development.

And let's face it, writing code is hard enough. Reading other people's code and trying to work with it is even harder. So do yourself a favor and write some tests. This way, you can be more certain that the changes you make are what you intended. Writing tests takes much of the guesswork out of your changes, which saves you time and ultimately makes you more productive.

Just add a test file

Take a baby step and just add a test file with a single simple test to get yourself over the hump. For me at least, the greatest barrier to entry is writing the first test (there's so much setup, so much boilerplate, I think to myself). Once a test file is established and even a single test is written, it becomes so much easier to build upon it. I usually write something like "it returns true" just to warm up, and then just that act removes the mental block I established, freeing me up to get into the more complex parts of the business logic.

Try writing descriptive tests first

If you aren't sure of the interface you want just yet, try writing descriptive tests first. That is, write the code you want, then write the test. Getting into the habit of writing a test is better than writing no test at all. (Truthfully, I have never regretted writing a test, not even once that I later deleted because I learned more about the expected behavior and results.)

With descriptive tests, you might miss a couple edge cases, but hey, you do need a starting point. Writing tests allows you to write garbage code first and later refactor, guaranteeing that you don't change behavior while you're changing code. It's sort of like writing an essay and just getting a bunch of brainstorming nonsense out before you edit.

Refactor

Once you've written your tests, you can begin refactoring and see what pleasure the ability to change code confidently brings. No more guessing. No more praying. Just sweet peace of mind. Plus, with confidence comes saved dev cycles.

Start doing TDD

After you're used to writing tests, try writing them first, before you've written the code to make them pass. I like to write out all the cases I know about and then I build upon them as new ones are discovered or use cases change. Then I refactor to my heart's content, never straying too far into red and always committing on green. Soon it will become habit and you'll feel gross not writing the tests first. At least I do. I get nervous every time I write code without a corresponding test, so I basically test everything I can within reason. I typically stick to testing public-facing methods, but if I'm dealing with time or money, two notorious sources of bugs, I'll even test private methods to make sure I get the logic right. Tests have saved my life so many times that I've actually lost count.

Spread the word

After you've seen the magic of TDD, I bet you'll want to spread the word, too. TDD is super fun, especially when combined with ping-pong pairing. It documents your code, helps you organize, and also lets you refactor until you're happy, which may or may not mean you've achieved elegant code, but no matter—getting your code under test gives you the ability to achieve elegance one day, and for now, practically speaking, that is probably good enough.

Fixing Random, Intermittent, and Flaky RSpec Test Failures

Tracy Lum — Mon, 05 Nov 2018 14:53:53 +0000

In my view, there's almost nothing more annoying than a randomly failing, intermittent, flaky test failure. Run the test suite locally and everything passes. Run it on a CI service, and your build fails! A single red! 🔴 Rebuild it again, and somehow, magically, it goes green.

A flaky or flickering test can create space for lots of noise and uncertainty. False negatives can delay deploys and shipping features. 🚢 An expected red failure may encourage developers to ignore true negatives and merge to master and deploy anyway.

Such was the general atmosphere on my team recently. Nondeterministic specs kept cropping up every few builds, eventually creeping up to about 50% of our builds on the master branch. And on a growing team, with looming launch dates, no one felt empowered enough to solve the flaky test issue. After all, hunting down a nondeterministic bug could take days, weeks, or more.

We kept saying we'd address it soon, but with our ops team working on a new deployment strategy that relies on passing builds, we finally prioritized
it. And I was the lucky individual selected to track it down.

This is the story of how I resolved this particular set of flaky test failures.

Unexpected Failures 😕

For the past few months, I've been making a lot of backend, systemic, and wide-reaching changes to my team's codebase to support a migration to GitHub Enterprise. And I mean the entire codebase, from our main Rails monolith, to our open-source gems, to our IDE, and to our chat service. That work warrants its own post, so for now, suffice it to say that our platform is deeply integrated with GitHub, depending on it for everything from avatars and usernames to hosting our lesson content.

Anyway, in order to decouple our platform from GitHub, my squad and I set out to introduce the concept of a LearnAccount separate from a GithubAccount, which keeps track of a Learn-specific identity and a GitHub-specific identity, respectively.

Being the responsible team members we are, we replaced every method call
meticulously and backed up our changes with specs. For the new LearnAccount model, which belongs_to a User model, we created a factory using Thoughtbot's Factory Bot. And we use the Faker gem to create reasonably realistic and random test data to work with.

FactoryBot.define do
  factory :learn_account, class: Identities::LearnAccount do
    username    { Faker::Lorem.word }
    user_id     1
  end
end

The new factory for the GithubAccount was essentially the same.

We also added a trait to our Users factory so that we could selectively create learn_accounts for the users we create in our tests. We definitely didn't want to persist more records than necessary, which could slow down our test suite.

FactoryBot.define do
  factory :user do
    email { Faker::Internet.email }
  end

  trait :with_learn_account do
    after(:create) do |user|
      user.create_learn_account
    end
  end
end

This all seemed fine. We launched the new feature, removed the old code, and then the test suite began to fail occasionally. The most common test failures would look something like this:

1) Api::V1::UsersController Switch active batch or track POST #switch_active_track given track within students current active batch updates the current track
Failure/Error: learn_account.username
     NoMethodError:
       undefined method `username' for nil:NilClass
     # ./app/models/user.rb:185:in `learn_username'

 1) Api::V1::StudyGroupsController PUT update rsvp_update rsvped returns a status 200
     Failure/Error: learn_account.username
     NoMethodError:
       undefined method `username' for nil:NilClass
     # ./app/models/user.rb:185:in `learn_username'

 1) CoursesController GET courses/:course_slug/sign-up user has email in session user's email already exists in the db user has login credentials redirects user to sign in and stores slug in session
     Failure/Error: expect(session[:course_slug]).to eq(course_slug)
       expected: "batch-123"
            got: nil

It was often different tests from different domains in our codebase, but the error would always look similar to one of the above test failures.

Reproducibility 🤷🏻‍

The first issue I encountered was trying to reproduce the failing specs. I kept re-running the specs locally, and they simply wouldn't fail. I did this over and over again, and began to fear for my sanity. And yet, on CircleCI, builds kept failing. I'd re-run those as well, and sometimes they'd fail, and sometimes they'd pass. I looked a bit into the various Circle configs, wondering if some misconfiguration was causing tests not to clean up after themselves. I also searched our local rspec configs just in case, but came up empty.

Then I scoured the other internet literature, looking for other strategies to solve flaky tests. Among the most helpful posts were the instructive ones on how to use RSpec's bisect flag. When used along with RSpec's --seed flag, the bisect option would "run subsets of your suite in order to isolate the minimal set of examples that reproduce the same failures," according to the RSpec docs. This allows you to identify order-dependent test failures. Meanwhile, the seed option allows you to randomize the specs to run in the same order. You'll need to use both flags to make this work:

rspec --seed 1234 --bisect

This wasn't the final solution, however. The first few times I ran this on a single test file, the failing tests would not make themselves known. I knew in my mind that if I could just get one to fail consistently, I'd solve the rest. But finally, I was able to reproduce the failing spec with the command above. And with that minimal reproduction command, I was able to get deterministic test runs and further isolate the problem.

The Fix 🛠️

With reproducibility, I could look closer at the code and identify the issue. Because it wasn't the same test failing all the time, I realized that the problem wasn't with the tests themselves, but with the data setup. Usernames for our LearnAccounts and GithubAccounts must be unique, but our factories weren't always generating unique values, which resulted in the LearnAccount and GithubAccount associated with a User failing to be persisted in the database because they weren't valid. That explained why the learn_account and github_account was sometimes nil.

In fact, we were using the Faker gem to generate values that approximated real values, specifically Faker::Lorem::Word. There are only 249 values in that collection of words, so there is a non-trivial chance of collision. (Yes, there's a supplemental collection of values, but more words still doesn't guarantee uniqueness.)

So, the fix was to ensure that the generated usernames in the tests would always be unique, and I did that by using Factory Bot's Sequences to append a unique integer to the end of a generated value.

Our factories now look like this:

FactoryBot.define do
  factory :learn_account, class: Identities::LearnAccount do
    sequence :username do |n|
      "#{Faker::Lorem.word}-#{n}"
    end
    user_id     1
  end
end

I ran the test suite locally and on Circle a few dozen times more, all with passing builds, merged this change in, and celebrated by blocking all future merges to master without a passing test suite. Just kidding, I also alerted our team via Slack and scattered a bunch of fingers-crossed emojis everywhere. 🎉🤞🏼So far, so good. All greens ✅.

Key Lessons Learned 🗝️

It's important to tackle random test failures the moment they're introduced.
RSpec --seed and --bisect can help you isolate the problem.
Sometimes it's not the test, but the data backing the test. i.e. Don't rely on Faker to generate unique values.

(Bonus Lesson) I'm getting way too into emojis. 🚀

Resources

Which Data Structure Should I Use? An Elixir Cheat Sheet

Tracy Lum — Sun, 02 Sep 2018 01:59:07 +0000

As an Elixir novice, I think one of the hardest things about getting started in Elixir is figuring out what kind of data structures to use. My team has recently started going all in on Elixir, so I've been trying to brush up in earnest. Often, however, I'll be reading over some of my team's code and have a hard time deciphering what I'm even looking at. The syntax looks very similar to Ruby (which I know pretty well), but the patterns, conventions, and data structures are just slightly different. In my mind, that makes sense since it's a functional rather than object-oriented language: where you would use objects in Ruby, you're probably spawning processes instead in Elixir.

But anyway, since I'm learning Elixir now, I thought it'd be useful to provide a cheat sheet or overview of the differences in data structures I've noticed as a Rubyist exploring Elixir.

Data Types

If you're coming from Ruby (or most other programming languages), integers, floating-point numbers, ranges, and regular expressions are all probably familiar to you. Fortunately, those all exist in Elixir too. There are a few differences, but I haven't dealt too much with them yet.

Atoms are like symbols in Ruby. They begin with colons and their names are their values. For example, :hello is a valid atom in Elixir. They're often used to tag values.

There are also strings in Elixir. Strings always have double quotation marks, while charlists are in single quotations marks. Strings are binaries, and charlists are actually just lists of code points. I have rarely used charlists so far.

Here's a quick glance at what those types look like

iex> 2         # integer
iex> 2.0       # floating point
iex> false     # boolean
iex> 1..4      # range
iex> ~r/hello/ # regular expression
iex> :hello    # atom
iex> "world"   # string
iex> 'world'   # charlist

Elixir has the additional data types, Port and PID, which are used in process communication. They are entities that are made available through the Erlang VM.

Port

A Port is used to communicate (read/write) to resources outside your application. They are great for starting operating system processes and communicating with them. For example, you might want to open a port to run an
OS command, like echo.

You could open a port and send it a message, like this:

iex> port = Port.open({:spawn, "echo sup"}, [:binary])
#Port<0.1305>

Then, you can use the flush() IEx helper to print the messages from the port.

iex> port = Port.open({:spawn, "echo sup"}, [:binary])
#Port<0.1305>
iex> flush()
iex> {#Port<0.1305>, {:data, "sup\n"}}
iex> :ok

You can send a port any name of a binary you want to execute. For example, from the directory of my jekyll blog, I opened up an iex session, opened a port, and then sent the bundle install command, which installed all the Ruby gem dependencies. Here's a snippet of the output.

iex> port = Port.open({:spawn, "bundle install"}, [:binary])
#Port<0.1306>
iex> flush()
{#Port<0.1306>, {:data, "Using concurrent-ruby 1.0.5\n"}}
{#Port<0.1306>, {:data, "Using i18n 0.9.5\n"}}
{#Port<0.1306>, {:data, "Using minitest 5.11.3\n"}}
{#Port<0.1306>, {:data, "Using thread_safe 0.3.6\n"}}
{#Port<0.1306>, {:data, "Using tzinfo 1.2.5\n"}}
{#Port<0.1306>, {:data, "Using activesupport 4.2.10\n"}}
{#Port<0.1306>, {:data, "Using public_suffix 2.0.5\n"}}
{#Port<0.1306>, {:data, "Using addressable 2.5.2\n"}}
{#Port<0.1306>, {:data, "Using bundler 1.16.2\n"}}
{#Port<0.1306>, {:data, "Using coffee-script-source 1.11.1\n"}}
{#Port<0.1306>, {:data, "Using execjs 2.7.0\n"}}
{#Port<0.1306>,
 {:data,
  "Bundle complete! 4 Gemfile dependencies, 85 gems now installed.\nUse `bundle info [gemname]` to see where a bundled gem is installed.\n"}}
:ok

PID

A PID is a reference to a process. Whenever you spawn a new process, you'll get a new PID. Expect to talk a lot about PIDs. You'll probably need to hold onto PIDs so you can send different processes messages.

Here's an example of spawning a process and getting the PID back.

iex> pid = spawn fn -> IO.puts("hello world") end
iex> hello world
iex> #PID<0.123.0>

The process dies after it has done its job. PIDs and Ports warrant their own standalone post, but for now, I think it's sufficient to just be aware that they exist.

So, now that we've added our new types, this is our basic cheat sheet.

The Elixir Data Type Cheat Sheet

iex> 2             # integer
iex> 2.0           # floating point
iex> false         # boolean
iex> 1..4          # range
iex> ~r/hello/     # regular expression
iex> :hello        # atom
iex> "world"       # string
iex> 'world'       # charlist
iex> #Port<0.1306> # port
iex> #PID<0.123.0> # pid

The real challenge with Elixir in my opinion, though, is figuring out how to organize these basic data types into structures you can use. So let's take a look at the various collection types and why you would use each.

Collection Types

Here are the collection types you'll likely encounter:

Tuples
Lists
Keyword Lists
Maps
Structs

You've probably heard those words before, at least in passing, but if you're accustomed to Ruby, you're probably wondering why you need all those extra types of collections. Let's investigate.

Tuples

Tuples are ordered collections of values. They look like this:

iex> {:hello, "world"}
iex> {1, 2}
iex> {:ok, "this is amazing!", 2}

# You can check if it's really a tuple
iex> tuple = { "hello", "world"}
iex> is_tuple tuple
iex> true

# and then you can get an element from a tuple by index
iex> elem(tuple, 1)
iex> "world"

I think tuples are a little wild. I mean, they look like they should be hashes, but they sort of behave like Ruby arrays. And then they're called tuples! It'll pay off to get familiar with them though, which is what I keep telling myself when I get confused for the hundredth time.

Tuples crop up all over the place in Elixir. Return values of functions are often tuples that you can pattern match on, so it makes sense to start seeing the world through tuples. Tuples usually have two to four elements, and at this point, they're my go-to data structure. When you're dealing with data structures that have more than four elements, that's probably a good case for using a map or struct instead.

Lists

Lists are linked data structures. They look like this:

iex> [1, 2, 3, 4]
iex> ["hello", "world"]

In Ruby, you'd think that was an array, but in Elixir, it's a list! Because lists are implemented as linked data structures, they're good for recursion, but bad for randomly retrieving an element or even figuring out the length because you'd need to traverse the whole list to figure out the size. To date, I've mostly been using tuples instead of lists. If you had to choose between them, I suppose you'd need to consider the expected size of the collection and what kind of operations you'll be performing on it.

Keyword Lists

To further complicate matters, there are also such things as keyword lists in Elixir. In essence, this is a list of two-value tuples.

# keyword list
iex> [ phrase: "oh hello", name: "tracy" ]

# is actually two-value tuples
iex> [ {:phrase, "oh hello"}, {:name, "tracy"} ]

This continues to baffle me, even though I am aware of its general existence.The cool thing about keyword lists is that you can have two of the same keys in a keyword list.

iex> keyword_list = [food: "peanut butter", food: "ice cream", flavor: "chocolate"] # a valid keyword list

Keyword lists are good for command-line parameters and options.

Maps

Next up are maps. If you wanted a real key-value store, not a list of key-values, this is what you're looking for. They look a bit like hashes in Ruby.

iex> %{"greeting" => "hello", "noun" => "world"}
iex> %{:greeting => "hello", :noun => "world"}
iex> %{greeting: "hello", noun: "world"} # if the keys are atoms, you can skip the hash rockets.

iex> greeting = %{spanish: "hola", chinese: "ni hao", english: "hello"}
iex> greeting[:spanish]
iex> "hola"
iex> greeting.chinese
iex> "ni hao"

Maps are good for passing associative data around, and pretty much everything else that is bigger than tuple size.

Structs

Structs are like enhanced maps. They permit only certain keys and those keys must be atoms. Structs need to be defined in modules with reasonable default values. They're maps with rules.

iex> defmodule IceCream do
....   defstruct flavor: "", quantity: 0
.... end

iex> chocolate = %IceCream{flavor: "chocolate"}
iex> chocolate.flavor
iex> "chocolate"

You'll see that the struct is defined with the same % percent symbol as a map, but it's followed by the name of the module. That's how I remind myself that they're just stricter maps.

Older versions of Elixir used to also include the HashDict to handle maps with more than a couple hundred values, but that module has been deprecated in favor of the good ol'fashioned Map.

That brings us to the end of the common data types and collection types you'll see in Elixir. Although there are a number of differences between the two languages, there are some similarities. Of course, there's plenty more to learn about Elixir, the conventions, and the cool things you can do, but this (I think) is a good start to getting familiar with the language. Hopefully this'll serve as a decent guide to deciphering any Elixir you might encounter soon!

The Elixir Collection Cheat Sheet

iex> {:ok, "this is amazing!", 2}                                         # tuple
iex> ["hello", "world"]                                                   # list
iex> [ phrase: "oh hello", name: "tracy" ]                                # keyword list
iex> greeting = %{spanish: "hola", chinese: "ni hao", english: "hello"}   # map
iex> chocolate = %IceCream{flavor: "chocolate"}                           # struct

Resources

Basic Types on Elixir Lang
Programming Elixir by Dave Thomas
Hex Docs