The latest book club discussion was on three chapters of Clean Code dedicated to error handling, boundaries, and unit tests.
The main take-away from error handling was to anticipate an error and write your try/catch/finally statement. What occurs in the catch block so your program can run smoothly, without throwing an ugly exception? (Though you may want that exception to occur in a development or test environment.)
For the boundaries chapter, my colleague pointed out an good use case. Consider that you are working on code that relies on input ... that is not finalized. As your team and the other team work, your team has to make assumptions about the input. One solution is to view that as a natural boundary. What helps you cross the boundary is a method you write that processes team 2's finished product into the structure you were expecting while your team coded.
Unit Tests. This chapter highlighted good testing practice. As a developer, I should value test code as much as production code. In practice, that doesn't always work out. I plan to write some tests for this app and return with a better entry about unit testing.
posted 2015-08-09 11:50:24 -0700 by Belda
Rails 4 fingerprinting causing 404 for bootstrap assets in production environment , tagged: ["ruby-on-rails-4", "asset-pipeline", "bootstrap-sass", "asset-finger-printing", "precompile-assets"]
How to run spec for a gem in your path , tagged: ["ruby-on-rails", "ruby", "rspec", "gem", "rails-engines"]
How to test module using concerns and associations, via dummy ActiveRecord model in specs , tagged: ["ruby-on-rails", "ruby", "activerecord"]