Learning: an excuse for not doing anything

“The more I read, the more I acquire, the more certain I am that I know nothing.”
― Voltaire

Software development is such a wide field. When I first learn to code, I never dreamed about about these continuous integration and code coverage stuffs, and testing was just making sure that your code outputs the right thing.

Actually, I’m still somewhat right on that last part. After all, all those tools ultimately mean to be used for “making sure your code outputs the right thing”. Just more automatic, more rigorous, more thorough, and simpler (or should be simpler, at least).

Enough philosophizing, here are reviews of what I have learned this past week. These might be reiterating what my teammates has write, but oh well, it’s not like I have anything else to do ¯\_(ツ)_/¯  besides MPPI assignment.


A Ruby testing tool, said to be created specifically for BDD (Behavior-Driven Development), a successor of TDD. You still write tests before code, but the tests are written with how the code should behave in mind, or more technically, specifications of system behavior. To quote Tutorials Point:

RSpec does not put emphasis on, how the application works but instead on how it behaves, in other words, what the application actually does

Scratch that. I don’t get it either. So here’s an example :

# spec/string_calculator_spec.rb
describe StringCalculator do

  describe ".add" do

    context "given an empty string" do
      it "returns zero" do
        expect(StringCalculator.add("")).to eql(0)

    context "given '4'" do
      it "returns 4" do
        expect(StringCalculator.add("4")).to eql(4)

    context "given two numbers" do
      context "given '2,4'" do
        it "returns 6" do
          expect(StringCalculator.add("2,4")).to eql(6)


To put it simply, instead of just telling “the right output is this“,  BDD encourage context: “in this context, given this input, it should return this“. Arguably, that’s just a fancier and more verbose way of saying the basically same thing. In practice, BDD is far more intricate of course. The specification must have such clear narrative that you might think you’re talking to a five year old.

That said, I understand that you write code for other human to read, and clarity is crucial, so that much verbosity is needed. We humans are stupid after all.


So your code might have passed your tests. But have you tested enough? How could you know? That’s a question for Code Coverage tools.

At first I was confused. How does one check whether the tests are enough? Who test the tester? Is it all test all the way down? Someone on StackOverflow has a pretty good answer which makes me feel pretty stupid afterward:

Code Coverage is a measurement of how many lines/blocks/arcs of your code are executed while the automated tests are running.

Of course maybe the implementation is not as simple as that, but the point stands. seems like Codecov also have the same idea, as seen in their docs:


So a Code Coverage Tool will run the test, then check the code line by line to see if it’s executed or not. Sound pretty simple right? Well yes, except checking whether a block of code has been executed or not is apparently not that easy.

In practice, doing the instrumentation is hard, because reliably identifying the basic blocks is difficult due to variation of syntax across languages.

Based on a paper(!) I found about code coverage.

But this paper has to wait, because I have another MPPI paper to read :v so that’s all for this week.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s