Rails testing and Emacs mode line

I’ve been diving/digging into the oh-so-excellent Rails Tutorial, by Michael Hartl, and am into chapter 3, where testing begins.

Imagine my surprise — go ahead, imagine it — when my Emacs mode line changed color.

Originally:

modeline_original

And when I ran “bundle exec rake test”, it succeeded with:

modeline_success

Then changing the test code to fail, after running “bundle exec rake test” again:

modeline_failed

Tracking down this code, I found that the guard-notiffany gem was doing this behavior, sending a change to the Emacs mode line via emacsclient, with this bit of code in lib/notiffany/notifier/emacs.rb:

        def notify(color, bgcolor)
          elisp = <<-EOF.gsub(/\s+/, " ").strip
            (set-face-attribute 'mode-line nil
                 :background "#{bgcolor}"
                 :foreground "#{color}")
          EOF
          emacs_eval(elisp)
        end

The issue there was that it just changes the mode line “permanently”. I’d prefer that the mode line colors change for a moment, then time out and revert to their previous settings.

I wrote a bit of code to do this, and modified lib/notiffany/notifier/emacs.rb locally, but there is a pending pull request that has a better implementation.

However, my hack is:

        def notify(color, bgcolor)
          elisp  = "(let ((orig-bg (face-attribute 'mode-line :background))"
          elisp << "      (orig-fg (face-attribute 'mode-line :foreground)))"
          elisp << "     (set-face-attribute 'mode-line nil"
          elisp << "                         :background \"#{bgcolor}\""
          elisp << "                         :foreground \"#{color}\")"
          elisp << "     (sit-for 3)"
          elisp << "     (set-face-attribute 'mode-line nil"
          elisp << "                         :background orig-bg"
          elisp << "                         :foreground orig-fg))"
          emacs_eval(elisp)
        end

The sit-for keeps the mode line as red or green for 3 seconds or when there is Emacs input. I prefer that, to clear the mode line more quickly, since I find the bright color distracting.

Tests Result in Better Programs, and Programmers

It’s widely noted and accepted that tests result in better code. My conjecture is that tests result in vastly improved programmers.

Even with a good test suite, the first implementation of a project will be utilitarian, complying with the edict of “just get it working!”. This are the red and green phases of the red/green/refactor cycle: red is when the tests fail, and green is when they pass. Too often, that initial version is the end of the cycle for many programmers and projects, which is why, in general, version 1 of a program is horrible:

win101logo

In the refactoring phase the project goes from simply “working” to being well-crafted. Thus the programmer as well has changed their mindset from writing “working” code to writing well-crafted code, and the programmer has been elevated to a higher level of craftsmanship.

Refactoring code is when a programmer can develop their skills and push the boundaries of their knowledge, such as delving into advanced object-oriented programming and metaprogramming, which are often considered dauntingly complex and risky. But used properly, they can dramatically improve a project, and I believe what is more important, they can dramatically improve the programmer.

In my experience, this was first proven to me when I was working on a large C++ project, my module being our persistence layer, providing a J2EE-like (but vastly simpler) interface with PostgreSQL. Although in that era (the late 1990s) Test-Driven Development hadn’t become popular, my daily goal was to write more test code than “real” code, usually between 500 and 1500 lines per day, usually, but not always, writing my tests first.

As my test suite grew and I became more confident in its ability to catch errors, I pushed my knowledge of C++, particularly with templates and the Standard Template Library, eventually reaching a point when I really understood the magic of the STL code. Had I not had such tests, and thus confidence, I likely would have refrained from pushing myself into an area that previously was in the dark, murky area of C++ to me, and I would not have gained valuable expertise as a C++ programmer.

In fact, I’d say that it’s only because of tests that I’ve felt confident learning a new language, such as when I rewrote DiffJ in JRuby, a language I hadn’t used. Having a thorough test suite made the learning process much easier.

The bottom line is that programmers must understand that testing includes refactoring (including of the test code itself), and that the refactoring phase is where programmers, and projects, can become significantly better.

Oh, and with thorough refactoring that horrible version 1 can eventually lead to significant improvements:

macos

Tests Result in Better Coders

We know that tests result in better code. They also result in better programmers.

The first implementation of a project will often be utilitarian, complying with the edict of “just get it working”. Code will be written and tweaked until the tests pass, but there are few cycles, if any, devoted to refining the code to be higher quality. This the red/green/refactor cycle is limited to just red and green.

The refactoring phase is where the code goes from simply working to being well-crafted. As the mindset of the programmer changes from being focused on utility to being focused on quality, they program accordingly different.

With the principle of quality being foremost, and with the confidence from having a thorough set of tests, the programmer can also push the boundaries of their knowledge, such as delving into advanced object-oriented programming and metaprogramming, which can be dauntingly complex and risky. Those areas do not necessary have an immediate impact on functionality, so when a programmer is in functionality/utility mode, they’re less likely to employ those techniques. However, in quality mode, a programmer will feel more justified, and confident, in using those techniques, which over the long term can cause a dramatic improvement to a project.

Often forgotten is that both code and tests should be refactored. Test code that is unclear, misleading, or just wrong can be very frustrating to someone trying to understand a body of code, since the tests are the best starting point.

The bottom line is that programmers must understand that testing includes refactoring (including of the test code itself), and that the refactoring phase is where programmers, and projects, can become vastly better.

Related posts: