Wrapping Up Ruby, Serenely | Day 6
It seems as though the biggest hurdle has been overcome, with the foundations of Ruby out of the way. Today was mostly a discussion on the fundamentals of test driven development (TDD), as it relates to development in Ruby, along with other similar testing philosophies. The week ahead feels much easier as we transition into HTML, CSS, and JS – a place of relative comfort for me compared with Ruby. Personally, I’d like to think of this week as the calm before the storm: we begin with a direct immersion into Ruby, followed by a breather with HTML/CSS, followed by a tumultuous plunge into Rails. I’m really looking forward to catch my breath this week!
That being said, I’m still building on the weaknesses that I feel in my grasp of Ruby. I’ve gone through most of the Treehouse content on Ruby fundamentals at this point, along with finishing Huw Collingbourne’s beginner’s course on Ruby; I plan on going through Codecademy’s Ruby’s content before the end of the week. I think these three resources are perfect for any beginner when used together. Treehouse and Collingbourne’s course provide an informational context through lecture heavy content while Codecademy provides direct coding practice. These resources have been invaluable to me in tackling the various coding projects at Bitmaker Labs. Eventually, I will be rounding off my Ruby basics with Code School material and the Hartl tutorial, but that is still further down the road.
Anyhow, with TDD on the list of priorities for today, we built tests for the programs that we wrote earlier in the course. During our lecture, we learned that these tests are written principally to catch errors, to save time (spend time to save time), and to have clean code. The two major schools of thought that we looked into were Test First and TDD, which actually have more in common than they are different. Broadly, you can say that Test First applies when you have a conceptual understanding of what your program will look like and hence you can architect all of your tests at the beginning, before building out your product. When I heard that description, I immediately thought of the traditional waterfall development process. On the other hand, when you’re not exactly sure of how your end product will look like, TDD is your true companion. It seems to work best with an agile development process where the testing becomes an essential component of the development – an intermeshed unity.
In terms of the levels of tests, there are unit tests, integrative tests, and functional and acceptance tests. You can think of unit tests as atomic in nature – they deal with isolated chunks of code. Integrative tests are a step up from unit tests and focus more on the interaction between the various units. If the unit tests focused on individual islands, the integrative tests would focus on the ecosystem of those islands as a collective entity. It is important to note that these first two tests are from the developer’s perspective. The functional and acceptance tests are viewed from the user’s perspective (e.g. black-box testing) such that you’re focusing on the deliverables that your average customer will be concerned with. For instance, the average Facebook user does not care what specific code is being used at any given moment – one is simply concerned whether or not one can connect with one’s friends, upload photos, and send messages etc. Following that discussion, we also took the time to go over the Ruby testing frameworks: (1) Test-unit, (2) Mini-test, and (3) Rspec. Personally, I feel better suited to Rspec as it is focused more on writing specifications rather than explicit tests; perhaps, as I grow in skill, I’ll see the value in Mini-test but that won’t be for a while.
Finally, one key take-away from the lecture on TDD was the five elements of a good test, namely:
- A good test is isolated,
- A good test, tests the APIs, not the internals,
- A good test is quick to write,
- A good test is quick to run, and
- A good test is unique.
Following the content portion of the lecture, we explored various test files on Github like Shopify/active_merchant, sparklemotion/nokogiri, stripe/stripe-ruby, and colszowka/simplecov (with an emphasis on how useful simplecov was as a barometer for how well a given program is being tested). Nonetheless, what I gathered from this little excursion is that if one is launching a tech startup, one definitely needs to have a GitHub account exclusively for one’s company – not contributing to the open source movement would be a fatal move. On that note, I recently initiated a Quora question, asking for good introductory texts on the history and philosophy of the Open Source movement. Two prominent texts that came up were “The Cathedral and the Bazaar” by Eric S. Raymond, and “The Open Source Alternative” by Heather J. Meeker. I recently bought them and would recommend them eagerly to my fellow open source enthusiasts, so we may learn more about the history of the movement that we are contributing to through our growing GitHub profiles.