Objects, Methods & Integers
Last updated
Last updated
In Ruby everything we interact with is an object. That includes basic data types like numbers, strings and even nil
. Every value in Ruby has an underlying object representation and can be manipulated with methods.
Ruby is also known to be "weakly typed", which means that type checking is not strictly enforced. This feature allows variables to change types dynamically at runtime. Example:
The object-oriented approach combined with the dynamic type system make Ruby a powerful and flexible language. In this chapter we're going to use these features to code a decimal to binary converter.
The numeral system humans are used to use is the decimal system. It has this name because it uses ten different digits to represent the values: 0
, 1
, 2
, 3
, 4
, 5
, 6
, 7
, 8
, 9
.
The is a way to represent vaues using only two digits: 0
and 1
. As it only needs two digits, we can say it's a base two number system.
For computers the binary system is extremely efficient because they need to store information in only two simple different states: "on" or "off" (1
or 0
). Sets of binary numbers can be used to represent any information, such as text, audio, or video.
For the code we're going to work on this chapter I'm assuming you at least know what a binary number is and that it's a base two number system.
You don't need to know the math needed to convert a decimal number to binary notation (Ruby has convenient ways to do it). But I'm assuming you know that the binary 1001
is not one thousand and one (you don't need to know that it represents nine).
If you need more information on this topic, can be a good start.
The very first thing is to create a directory for us to work:
Now let's start our Decimal to Binary Converterâ„¢ project following the TDD cycle:
Write a test
Run the test, see it fails and check the error message
Write enough code to make the test pass
Refactor
We still have no idea about how to implement this converter, then how can we write a test for a code that doesn't even exist?! That's a strong and valid question. The answer is: write the test using the best interface you can think of to perform the operation.
Keeping this in mind, I list here my ideas for a great interface to a class able to convert a decimal number to its binary representation:
a class named NumberConverter
a method named dec2bin
it accepts an integer number as the only argument
it returns the binary representation of the given number
Something like this:
Yeah, that looks good.
0
0
1
1
2
10
3
11
4
100
5
101
6
110
7
111
8
1000
Let's use 8 to write our first test.
Create a file named number_converter_test.rb
:
Run this test and check the error message.
Remember: you must either use the keyboard shortcut to trigger the test or use
rerun -x -- ruby number_converter_test.rb
.
We got an error...
By writing the minimal amount of code for the test to run we're letting the tests guide our development. That's a core concept of Test-Driven Development. The main benefits with this principle is to take small steps and prevent over-engineering your implementation.
Back to the error message:
We're requiring a file that doesn't exist.
Create an empty file named number_converter.rb
, and check the next test results:
Now the error message says NameError: uninitialized constant TestNumberConverter::NumberConverter
.
When we create a class, the class's name is a constant. That's why the error message says uninitialized constant
. To solve this we must create the class in the number_converter.rb
:
New error message:
It's complaining that the method doesn't exist, then let's create it:
New error message:
Let's fix the wrong number of arguments
in our dec2bin.rb
:
Now we have a failure message:
Our test is finally running with no errors! It's failing, but at least it has no errors. We're almost there!
You may be thinking that you're wasting your time in this tedious loop of checking the test error message and writing the minimal amount of code to fix the error message. The point here is that it is a nice way to prevent over-engineering. Your tests are the "executable requirements", and your software just needs to meet such requirements.
The failure message says that the expected result is "1000"
but it received nil
. So, let's fix this like a pedantic programmer and "write the minimal amount of code to make the test pass" (this is what Kent Beck calls "fake it 'till you make it"):
Ah hah! Foiled again! TDD is a sham, right?
Maybe we should add another assertion to our test in number_converter_test.rb
:
Test results:
Let's stop here and start to work on the code that will actually convert a decimal to its binary representation.
In the beginning of this chapter I said: every value in Ruby has an underlying object representation and can be manipulated with methods. This includes the integer numbers. They are objects and we can interact with them using their methods.
Another fact about Ruby objects is that all of them have a string representation that can be obtained by the #to_s
method (to_s
stands for "to string").
As our goal is to convert a decimal to its binary representation, and this representation is written in a string, maybe we can get some help from Integer#to_s
.
In that page we can see a pretty decent amount of information about Integers, including what they can do (in other words, which methods they have).
to_s(base = 10) → string
Returns a string containing the place-value representation of
self
in radixbase
(in 2..36).
Hey! Although the description can sound kind of cryptic, the example looks promising!
The method accepts an argument that acts as the base for the string representation we want to get from the integer. As the binary system uses base two, let's check if it can be used in our converter.
Before opening our code editor and writing our implementation, let's play a bit in the Interactive Ruby Shell (irb
).
We want to check if Integer#to_s
is able to give us a binary representation of an integer. So, let's try it with 8.to_s(2)
:
Yeah! That seems to be exactly what we want! Let's try different values:
Alright! I'm convinced! Let's use this method in our converter.
Now that we know Integer#to_s
can solve our problem, let's use it in our code:
Results:
Great! All tests passing means that it's time to refactor.
There's no much room for refactoring in a single line function. However, the refactoring phase is not just about the tidying up the production code. The tests also deserve to be tidy.
Currently our test class looks like this:
So far I've been writing tests assigning values to expected
and actual
variables and then passing them to assert_equal
. I did this for a didactic reason, just to make it explicit that an assertion involves a comparison between an expected value and the actual value. Now that you (hopefully) already got the idea, we can make the testing code more concise.
First, as we instantiate an object for just one method call, we can do it with a single expression, like this:
The second change towards conciseness is that we can inline the expected value and the method call in the assertion line. Now our test file can look like this:
Run the tests and they should still pass. Therefore, it's time for another round of refactoring.
One important aspect of tests to keep in mind is: we should have one test per behavior. If we look carefully, both tests we currently have are testing the same behavior, a simple case of converting an integer to its binary notation. So, I think both tests should be merged into one (and the test should be renamed accordingly):
The tests should be passing now, and I think for now we're done with this refactoring session.
Commit your changes and let's move on.
Now that we have working software, backed by tests, we should be safe to use it in a "real" application.
Let's write an extremely simple application that reads a number from user's input and prints the binary representation of the number.
Create a file named exactly like this: d2b
. Note that there's no .rb
extension in the file.
Here are the contents to be put in the d2b
file (explanation comes right away):
The print
method is just like puts
, but it doesn't add a trailing newline. This is useful to keep the cursor right in front of the integer:
string.
The gets
method is used to get user's input. It returns the data submitted by the user, and we store it in the my_number
variable.
The rest of the code should be familiar to you and easy to understand.
In order to run this program, we need to give the executable permission to the file.
Now we're ready to run it:
Nice. It's waiting for our input. Let's give it a number.
😳 How could this happen? We used TDD to code our function and it passed the tests!
That's time to tell you a truth about Test-Driven Development: TDD is not a way to assure your code does not have bugs.
TDD is a way to facilitate and guide development, giving you short feedback loops (as you don't need to test your software manually) and lead your implementation to a better design.
Although TDD can reduce a lot the appearance of bugs, making sure your code doesn't have bugs is not something TDD can promise.
irb
After this frustrating news, let's try to understand what's wrong on our code. Check the main part of the error message:
The message says that the error happened in number_converter.rb:3
, which means in the 3rd line of the number_converter.rb
file.
The message also says that we passed a wrong number of arguments to the to_s
method (given 1, expected 0). But in the documentation we saw that Integer#to_s
accepts an argument. 🤔 Uhm... Is that number
really an Integer
?
In order to check that we're going to turn again to one of our best friends: irb
.
Ruby provides a way to open an irb
session from anywhere in your program using binding.irb
. This is helpful for debugging and is exactly what we need now.
Add binding.irb
right before the buggy line. Your number_converter.rb
should look like this:
Now let's repeat the steps where we faced the error:
Now we're on the irb
prompt, right before the point where the crash happened. How cool is that?! 🙂
👀 That's a String composed of a character 7
followed by a newline. That means that our dec2bin
function was called with a String as an argument!
Let's check our d2b
again, adding some notes:
This is an example of how Ruby's dynamism is a double-edged sword. It can be powerful and allow rapid development, but also requires extra attention. In this case the lack of type checking allowed us to pass an unexpected data type that crashed our application.
Now, before working in a solution for this bug, we'll apply another valuable testing practice: when you find a bug, replicate it in a test case before fixing it.
NOTE: once we found the bug, we can now remove the binding.irb
line from our dec2bin.rb
code.
Let's write a test giving the problematic String to the dec2bin
function:
Run the test and see if the crash was really replicated:
Nice! Now we can start working on a solution and quickly check if we're on the right path.
This is an example of how the Ruby's dynamism can promote rapid development. If we were coding with a strongly typed language, we would need to code different functions to allow receiving different data types. With Ruby we can code only one function and work on ways to handle the dynamic typing. As you can notice, everything is a trade-off (and if you're reading until here, you probably like Ruby's dynamism).
In order to fix the bug we just need to chain to_i
and to_s
:
Run the tests and they should be passing now.
Run the CLI again and it should work without crashing.
This is a good time to commit your changes.
As an exercise, I suggest you to implement other converters for the NumberConverter
class. For example:
dec2oct - a decimal to octal notation
dec2hex - a decimal to hexadecimal notation
Always keep in mind the TDD cycle:
Write a test
Run the test, see it fails and check the error message
Write enough code to make the test pass
Refactor
Let's recap what we learned in this chapter.
OOP: everything in Ruby is an object
Dynamic typing: variables can change types at runtime
String representation: all objects have a to_s
method.
irb
: quickly experiment Ruby code
binding.irb
is a useful debugging technique
p
: inspect the contents of a variable
gets
: read user's input
method chaining: calling multiple methods in sequence (e.g.: number.to_i.to_s(2)
)
Test-first approach: write the test before implementation code.
Test Error vs. Test Failure
Minimal implementation: write just enough code to make the tests pass (without being pedantic, please).
Test code also needs refactoring to stay tidy.
TDD guides the development, but does not assure our software is free of bugs.
Replicating bugs in tests: add test cases for discovered issues before fixing them.
But before creating an assertion, we need to know what would be a successful conversion. For this I use the , where we can see a table like this:
If our pedantic instincts evolve to the point where we want to be a prick, we could add an if in our code just to answer with "10"
when the argument is 2
. But that feels like .
As we want to work on Integers, we need to check the documentation about the Integer class:
We don't need to read all that page, but use it as a reference when needed. As we are suspecting the Integer#to_s
can help us, let's take a look at (below I bring only the part related to our problem):
In the very first line we're putting a to tell our OS which interpreter we wan to use to execute the commands in this file, in our case we're telling the OS to use the ruby
executable found in the user's PATH
(it's not necessary to know all the details here, but if you're curious can help).
Once we're on the irb
prompt we can run any Ruby code. An interesting way to inspect what's in a variable is by using . Let's use it to check what exactly is in the number
variable:
We're assigning a value to my_number
with gets
, which returns the user's input as a String. When we pass this string to #dec2bin
it calls String#to_s
instead of Integer#to_s
. And doesn't accept an argument. That's why our program is crashing!
Fortunately we can easily solve this issue by converting the string to an Integer using the String#to_i
method (). It's also fortunate that this method is also available for Integers (), even if it doesn't do anything, it's useful for cases like this, where we don't want to add logic to handle data types.
is an essential resource of information.