Software testing is necessary, but software testing is hard for beginners.

Before I was introduced to automated software testing, it seemed impossible to actually make sure everything worked in the apps that I made. Opening a browser and clicking around takes forever, especially in development mode in a Rails app. And what about that one weird edge case? Do these methods work together like I expect them to? Automated testing is only as good as your test suite, but it takes the manual labour out of figuring out if things work as expected.

The most important thing in this post: you should be writing tests for your code. If you’re not already doing so, I highly suggest that you stop reading right now and learn how to use one of the testing frameworks for your language of choice. If you use Ruby, check out Minitest. If you use Javascript (node), check out Tape.

Since my experience is with Rails apps, the easiest way to find out what to test is simply read the Rails Guide on testing. Rails, by default, uses Minitest as its testing framework, which is easy to pick up because it’s just Ruby code. Another popular framework is Rspec, which provides a DSL that allows you to write your tests in a way that looks more like english, although that means you need to learn the DSL to use it. Thoughtbot has a guide up that describes how they test with Rspec.

Aside from the testing frameworks themselves, there are several different testing methodologies that developers follow. One of the most popular, and the one that I’ll focus on today, is Test Driven Development (TDD).

What is TDD?

TDD is the idea that you should write tests first (which should fail – test that they do!), then write the code to pass those tests, then make that code better while it still passes the tests. In other (buzz) words: red, green, refactor. This is a tall order if you’re new to testing. In my case, a few months ago I hardly knew how to write tests, never mind write them before I wrote any code.

If you are new to testing, it can be helpful to write your tests after you’ve written your code, at least until you’re more comfortable with testing. Even if they’re written afterwards, your tests will still make sure your code works as expected.

Why use TDD?

Testing is important, but why does the order that tests are written matter? TDD will not make you a better programmer and not using TDD doesn’t mean you’re a terrible programmer. TDD is a tool that you can use that can aid in the design and implementation of your code. I use TDD because it helps me with:

1. Clarity of Design: When I’m forced to write tests first, I have to really think about the problem I’m trying to solve. What is the problem and what should the outcome be? When that is clarified in my mind, I write tests that make sure that outcome happens. All of that thinking is done and settled before I write a single line of code to solve that problem.
2. Instant Feedback: When writing tests second, there was always a feeling of “will it work…” before writing the tests. When writing tests first, the second I finish writing my problem-solving code, I can see if it works. There’s no waiting with bated breath, hoping and praying that my code solves the problem.

While there may be other benefits, these are the most important ones that lead me to try TDD in the first place.

How do I get started?

You are writing tests, right? Okay, good. Once you have writing tests down, the only step you need to follow is to write those tests before you write any other code. This will mean that you need to sit down and come up with a specification to the problem you’re trying to solve prior to solving anything. Then, put that specification into code with tests. Make sure those tests fail. Finally, write code to make those tests pass. Once they pass, make that code better.

A benefit of writing code to make tests pass is that you generally will only write enough code to make the test pass, and no more. Less code is often better code.

Some Caveats

While I’ve had some good experiences with TDD, I don’t think that it’s a perfect methodology and I don’t think that you should always follow it. DHH (the creator of Rails) himself has declared that TDD is dead. While I wouldn’t go as far as DHH, I do see some drawbacks to following it too closely.

The biggest one is that you’re often blind to edge cases when you’re first thinking out a specification to a problem. If you declare your test suite done prior to writing any code, and then don’t go back and add to it when you find a weird edge case, you will never know if a more recent change has caused a regressions. Regressions are never fun! When you find a weird edge case, write a test for it.

Another downside to TDD is that it can limit creativity in solving problems. If you’re just doing enough work to slip by the test, you could end up never putting the work in to find a much better solution. For beginners, like me, you’re also limited by your knowledge and ability with your testing framework.

Implementing TDD in my own workflow has been a net win for how I think and how I write code. You should give it a try and see how it can help you, too!

Just over half a year ago, I tweeted the following:

I love reading about automation, but I really can’t think of anything to automate. A curse of not using my own computer all day?

— Jonathan Pike (@jonathanpike) April 27, 2015

I love reading blog posts where clever people describe the scripts that they write to make their work (and, by proxy, their life) easier by automating boring, repetitive tasks. Back in April, I guessed that I didn’t automate because I couldn’t think of anything to automate. I’ve now realized that the boring, repetitive tasks that I have to do at work fundamentally can’t be automated because they are tasks that need a human touch. The tools and systems that I have at my disposal are very much a product of another time – a time where humans were the only “computers” that existed in an office.

Philosophizing aside, writing on this blog has actually produced a boring, repetitive task that was a perfect candidate for me to automate! Letting people know when I write something new is something that a computer is perfectly suited for. And so, I give you Pikebot. It’s just a simple Ruby script that fetches a blog RSS feed, determines if something new has been posted in the last hour, and, if so, posts the title and a link to that blog entry to Twitter. Couldn’t be simpler.

Through writing this little script, I learned a couple of things:

• An idea for automation doesn’t always need to be executed in the most grandiose way. I had visions of a command line Twitter utility that would allow users to specify their blog RSS feeds and set up cron jobs to handle the feed fetching automatically. While all of this is definitely technically possible, this idea wasn’t worth executing (for me, at least). Pikebot, in its current form, is perfectly capable at doing exactly what I want with minimal effort on my part.

• A Ruby script can be made much easier to execute by making it executable and putting it in a location in your PATH. This way, all I do is type pikebot in any Terminal window and it runs.

• Dealing with time is hard. When I was initially testing my script, it kept telling me “No new posts to tweet about” even though I had just posted something a minute ago. It took me a few minutes to realize that it was because my blog’s time zone is UTC (for whatever reason) and I was checking the time using Time.now (which was using EST). A quick and dirty fix was to change Pikebot to use UTC. Since I live in EST, converting to UTC was a pain, so I have my computer do it for me with another script called utcnow, which is included in the Pikebot repository.

Go forth and automate!

Previously on jonathanpike.net, I gave a run-down of most of the operators in Ruby, with the promise that I would cover certain omissions. The day has come, my friends, to address… bitwise operators!

Bitwise operators are not hard to understand but they’re also not intuitive. The key to understanding them is realizing that they work on a bit level. Bitwise operators work because Ruby stores integers in memory as a sequence of bits, which allows bitwise operators to manipulate these bits. Bitwise operators only work with Integers.

Binary Refresher

Understanding bitwise operators requires a basic understanding of binary numbers. Let’s use this variable as an example: a = 21. 21 is an integer, which is immediately recognizable to us (given our decimal/base 10 number system). Computers, on the other hand, work in binary/base 2. We can use the Integer#to_s method to convert a base 10 number to a base 2 number as follows:

a.to_s(2)
# => "10101"

If you’ve never been introduced to binary numbers, that may look a little confusing. A simple way of thinking about binary numbers is in terms of “columns”: each column represents a certain number and each column can be either a 0 or a 1. The columns go like this (from right to left): one | two | four | eight | sixteen | thirty-two | sixty-four … etc. If the bit in the column is 1, add the value of the column to the total, and if the bit in the column is 0, don’t add the value of the column to the total.

In our example, the ones column is 1, so we add 1 to our total. The twos column is 0, so we skip it. The fours column is 1, bringing our total to 5. Skip the eights column, which leaves us with the sixteens column. 16 + 5 = 21.

Bonus Content: here’s a super easy way to convert binary numbers to decimal numbers in your head without having to think of them in columns!

Back to Bitwise Operators

There are 6 bitwise operators in ruby, almost of which are binary operators (operators that work with 2 operands), as follows:

& - the AND operator | - the OR operator ^ - the XOR (exclusive or) operator ~ - the NOT operator – this is the only unary operator in the bunch >> - the right shift operator << - the left shift operator

A few of these look exactly like the boolean operators that I addressed last time and it turns out they work in a similar way.

AND

The & operator will look at the binary representation of both numbers and will return 1 when both numbers have a 1 bit in the same column. We’ll use our variable a as defined before, and we’ll define another variable to use as an example:

a #=> “10101”

b = 18
b.to_s(2)
# => “10010”

(a & b).to_s(2) 
# => “10000”

Since the only column that a and b had in common was the sixteens column, that is the only column that returned 1.

OR

The | operator works in a similar way to the & operator, but will set any bit that is 1 in either number to 1 in the return value:

(a | b).to_s(2)
# => “10111”

XOR

The ^ operator is the opposite to the &, and will only set a bit as 1 if that bit is 1 in only one of the two compared numbers:

(a ^ b).to_s(2)
# => “00111”

NOT

The ~ operator does exactly what you think it does: it flips all of the bits of the number (if they were 1, they are now 0). Strangely, the Integer#to_s method produces some odd output:

(~a).to_s(2)
# => “-10110”

What’s going on here? Shouldn’t it be 01010? The answer comes from how binary numbers handle negatives, and how the Integer#to_s method deals with negative binary numbers.

Binary numbers don’t natively have a negative sign to deal with negative numbers. Instead, they are represented through a method called two’s compliment. A really great explanation of how it works can be seen here¹. In a nutshell, to convert to two’s complement notation, the leftmost bit becomes the sign value (which reduces the range that your binary number represents), all of the bits are flipped (with the bitwise NOT), and you add 1.

Secondly, the Integer#to_s method does not actually return a true representation of binary numbers when dealing with negatives. Instead, it returns a representation of the number prepended with a negative sign. In this example:

~a #=> -22
(22).to_s(2) #=> “10110”

(~a).to_s(2) #=> “-10110”

Using the Fixnum#Fix[n] method, we can see the binary representation of each bit in our number, which shows NOTs true colours:

a = 21
b = ~a

5.downto(0).map { |n| a[n] }.join #=> “010101”
5.downto(0).map { |n| b[n] }.join #=> “101010”

« and »

The right and left shift operators simply shift an integer’s bits in the direction you specify. It will add 0s if shifting left and remove bits if shifting right, as per how many spaces you tell it to shift. For example:

a.to_s(2) #=> “10101”
(a >> 1).to_s(2) #=> “1010”
(a >> 4).to_s(2) #=> “1”

(a << 1).to_s(2) #=> “101010”
(a << 4).to_s(2) #=> “101010000”

So What?

All of this is interesting at an academic level, but it’s hard to think of a use for bitwise operators in day to day Ruby programming. Why have a feature that isn’t all that useful? The answer is that while this functionality may be specialized, it does have uses.

Calle Erlandsson wrote an article showing how bitwise operators are useful when dealing with file system permissions. Additionally, this Stack Overflow post shows several real-world uses for bitwise operators.

Credits

I owe a deep debt of gratitude to Calle Erlandsson’s article, Ruby’s Bitwise Operators. The content in this article has its foundation in the understanding that I got from his explanations.

It will be no surprise to you that I do a lot of research. One topic that has stood out to me in the research that I’ve done has been Ruby operators. While I may have encountered the term in high school math, I’ve since forgotten it in the intervening years. The more I read, the more of these operators I came across, some easy to understand and some inscrutable (at least at first). To make things more confusing, there are different categories of operators, too: unary, binary, and ternary.

My curiosity was piqued, but finding a list and explanation of all of these the operators in Ruby seems to be hard to come by. And as for a breakdown of what the different categories of operators are and how they differ? It wasn’t until I started reading Eloquent Javascript that I truly understood the relation between unary, binary, and ternary operators.

To help solidify all that I’ve read, researched, and learned, here is the most comprehensive rundown of all of the Ruby operators that I can provide. There is missing information (see “What I Didn’t Cover” below), but none of the included information should be wrong¹.

Operators in General

As far as I am aware, the term “operators” and the concept of operations comes from the world of mathematics. For example, when doing a simple calculation such as 1 + 1, + is the operator, and each 1 is known as an “operand”, or the value on which the operation is being performed.

Operators perform the same function in Ruby – they combine or act on inputs to produce an output. For example, something like !true (which uses the ! unary operator) returns false. The number of operands an operator acts on is called the operator’s arity.

Other important concepts are precedence and associativity, which both relate to the order of operations in a given expression. You may remember the acronym “PEMDAS” (Parentheses, Exponents, Multiplication, Division, Addition, Subtraction) from math class, which is a simple way of remembering the precedence of these operators. If you have an expression such as (1 + 2) * 3, you know that 1 + 2 will be calculated first, as it is in parentheses, and the result will be multiplied by 3. If you remove the parentheses from the expression so it is 1 + 2 * 3, you know that 2 * 3 will be calculated first, and the result will have 1 added to it.

Associativity deals with which direction the expression will be evaluated given operators with the same precedence. For example, mathematical operators are often left-associative, which means they are evaluated from left to right. 1 + 2 - 3 is evaluated (1 + 2) - 3, not 1 + (2 - 3).

Unary Operators (operators with an arity of 1)

Unary operators perform a function on a single operand. In my experience, unary operators are by far the hardest to understand.

• ! – Boolean Not. This one is simple – it simply produces the boolean opposite of the operand. In the case of the example above, !true evaluates to false. An equivalent operator is not, although it has a lower precedence than !.
• - – Unary Minus. Also simple, as it works exactly like you would expect – it changes the operand to negative, as in -1.
• + – Unary Plus. The opposite of the Unary Minus, but less useful. It simply returns the value of the operand (which is what you would expect).

• & – Unary Ampersand. So far, the operators that have been mentioned have not been confusing. What did I mean when I said that the unary operators in Ruby were the hardest to understand? The unary ampersand almost solely is responsible for my difficulty, because it works like magic.

  Starting from the beginning, Ruby has three different types of closures: blocks, procs, and lambdas. For this discussion, we’re going to just focus on blocks and procs. The big difference between blocks and procs is that blocks are second class citizens and are one of the few things that aren’t objects, whereas procs are objects. Blocks cannot be assigned to variables, for one thing, whereas procs can be.

  Many methods in Ruby accept blocks, which is great. You know a block when you see it: either between do...end or between curly braces ({ }) at the end of a method call. Inside of your method, you can yield to that block, which means that the block will be evaluated inside the context of the method.

  Going back to the difference between blocks and procs, what if you want to store one of these blocks as a variable? Tough luck, as blocks are not objects. However, you can store a proc as a variable and use the & operator in the method call, like so method(&proc). This will convert the proc to a block, which will then be handled by your method.

  Confusingly enough, the unary ampersand will also go the other way, converting blocks to procs so that you can store them in a variable and then .call them later, like so:

  Finally, & has one last trick up its sleeve. If you pass an object that is not a proc to a method that expects a block, it will also convert it from whatever it is to a proc, and then to a block for the method. This is insanity! It is also how amazing useful method chains like the following work:

  ”1 2 3”.split(“”).map(&:to_i)

  The method #to_i is being called as a block in map, changing each of the String objects in the array to Fixnum objects. Wow. I told you it was confusing. For a much more thorough examination, please see this article by Reginald Braithwaite.

• * – Splat Operator. You thought the unary ampersand was weird? You ain’t seen nothin’ yet! Essentially, it expands either an array or an object that can call #to_a and returns an array. Instead of explain it poorly myself (as I’ve never actually used it), I will point you to this great article by Adam Sanderson.
  
  

Binary Operators (operators with an arity of 2)

Binary operators are generally the most familiar operators to anyone who stayed awake in math class. In fact, many of the binary operators are mathematical operators, and they work the same way as when you use a pencil and paper and don’t need much explanation!

• ** - Exponentiation.
• * - Multiplication.
• / - Division.
• + - Addition.
• - - Subtraction.
• % - Modulo or Remainder Division. Returns the remainder of a division operation rather than the result. Great for testing if a number is even (ie. 4 % 2 == 0).
• < > <= >= - Less Than, Greater Than, Less Than or Equal To, and Greater Than or Equal To.
• <=> - Comparison. This one is a little different from the rest, as it’s less self explanatory. If both left and right operands are equal, the Comparison operator returns 0 (3 <=> 3). If the left operand is greater than the right operand, the Comparison operator returns 1 (4 <=> 3). And if the right operand is greater than the left operand, the Comparison operator returns -1 (3 <=> 2).
• == != - Equal To and Not Equal To.

One interesting implementation detail is that these operators are actually methods and can be called like any other method. For example, 3.+(3) == 6. That looks weird, though, so you shouldn’t do it.

Then comes the boolean binary operators:

• && - Boolean And. Both sides of the expression have to evaluate to true for the expression to be true. For example, true && false returns false, whereas true && true evaluates to true.
• || - Boolean Or. Only one side of the expression has to evaluate to true for the expression to be true. For example, true || false returns true.

These operators are not implemented as methods like the other binary operators.

Finally, there are the assignment operators:

• = - Regular assignment.
• += - Shortcut for variable = variable + a
• -= - Shortcut for variable = variable - a
• *= - Shortcut for variable = variable * a
• /= - Shortcut for variable = variable / a
• %= - Shortcut for variable = variable % a
• ||= - Or Equals. That’s my name for it, as those are the other two operators it combines. This one is a little bit tricky, and it’s best explained with an example. Take the following code: variable ||= []. This means that if variable is not specified elsewhere, it automatically gets assigned as an empty array. It is a shortcut for variable = variable || [], which makes a lot of sense when you expand it out.
  
  

Ternary Operator (operators with an arity of 3)

? : is the only ternary operator in Ruby. This is often known as the conditional operator and is a really slick way of making an if...else...end statement into a one-liner. In use, the ternary operator looks like this:

statement ? true condition : false condition

If the statement evaluates to true, the true condition will be evaluated, and vice versa. You can even link ternary operators together, such as:

statement ? second statement as first true condition ? second true condition : second false condition : first false condition

While this is nice for brevity, it is not as clear as simply doing a nested if...else...end statement, and generally confuses new Ruby programmers.

What I Didn’t Cover

If you look through this post, you’ll see one glaring omission²: bitwise operators. Why haven’t I included these? Because I don’t understand them yet! I’m still researching and trying to figure these out, but rest assured: once I do figure them out, I’ll post about them here!

Another omission is the idea of mixins and being able to redefine/implement some of these operators in your own classes. This is an OOP paradigm (composition) that I haven’t fully grasped yet, but I’m also researching and learning more about this. I intend to write a post about mixins as soon as I get a firm handle on them.

Credits

While some of the knowledge included here comes from trial and error, I have to thank the following sources for teaching me:

• The Ruby Programming Language - Chapter 4 (Operators)
• Ruby’s Unary Operators - Ruby Inside
• What is the Difference Between a Block, a Proc, and a Lambda in Ruby?

On Tuesday, I watched a really great talk about Ruby and Rails performance by Aaron ‘Tenderlove’ Patterson, the famous Ruby and Rails contributor. While there were many ideas and concepts in the talk that sparked my curiousity, the concept of regression test selection really stuck in my brain. What is it, and how does it work?

From my understanding, regression test selection is a simple idea. Consider the following scenario: you are a developer on an web application that has a great test suite and all of the tests pass. When you make a change to a small portion of your code base, you want to make sure that you haven’t introduced any bugs, so you’ll want to re-run your test suite. Running the full test suite can take a long time, and you only made changes to one small part. Why do you have to test those portions that weren’t changed and will surely pass? Regression test selection is the solution to this dilemma. Instead of running the whole test suite, you will only run the subset of tests that deals directly with whatever you changed. This will reduce the cost of running your tests and make sure that no bugs have been introduced. Amazing idea, right?

During his talk, Tenderlove demonstrated a regression test selector for Minitest and Rspec he wrote, which you can view here. It works with built in Ruby code coverage tools¹ to figure out what code a particular test executes, then looks at your git repository to see which files and lines were changed. Skipping all of the implementation details that you can read for yourself, it will end up spitting out the tests that are likely to fail with the change that you made.

Dyego Costa has taken Tenderlove’s idea and packaged it into a gem called What To Run to make it easy to integrate into your projects.

Regression test selection isn’t necessary for every project, especially if your test suite is fast. It is a real boon for projects with large, slow test suites, and the very idea itself really demonstrates the creativity and problem-solving mindset that draws me towards being a developer.

If you want a deep-dive into this concept, consider reading An Empirical Study of Regression Test Selection Techniques, which analyzes several different regression test selection techniques and discusses the cost and benefits of each.