Ketan's Musings

The last few weeks have been interesting working with SWT and some newly acquired (J)Ruby chops, to hack together a couple of approaches to build a recorder for SWTBot. Here is one of the interesting hacks which was cobbled together:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

require 'java'
module Recorder
  module SWTInitializer
 
      include_package 'org.eclipse.swt'
      include_package 'org.eclipse.swt.layout'
      include_package 'org.eclipse.swt.widgets'
      include_package 'org.eclipse.swt.custom'
      include_packate  'org.eclipse.swtbot.swt.finder'
 
      # loop through a few known classes to implement static imports
      def method_missing(method, *args, &block)
        klass = [
            org.eclipse.swtbot.swt.finder.matchers.WidgetMatcherFactory,
            org.eclipse.swtbot.swt.finder.utils.SWTUtils].find do |k|
          k.respond_to?(method)
        end
        return klass.send(method, *args, &block) if klass
        super
      end
  end
end

To use this class:

1
2
3
4
5
6
7
8

class Application
  include Recorder::SWTInitializer
  # the with_text invocation falls into the method_missing 
  # which delegates it to WidgetMatcherFactory
  def self.run
    SWTBot.new().widgets(with_text('hello'))
  end
end

Only Valid Measure of Code Quality

Image from http://www.osnews.com/story/19266/WTFs_m

WTF implies lack of clarity. Clear code is easier to understand, easier to maintain and easier to extend.

Announcing saikuro_treemap — an easy to setup tool to generate complexity treemaps of ruby code.

See a demo for yourself.

Complexity Visualization of Rake

Objects exposing behavior, not state

Controlling complexity of your codebase by limiting what state your objects expose

The more objects that can see and change states on other objects, the more complex your system. Objects returning a boolean mean that someone calling that method will use an if branch, returning an integer would mean someone using if/else or switch/case. Returning objects would mean introspeting that returned object to invoke something else on it. This increases coupling between classes, makes code hard to read and test.

My class has 3 friends, I talk to my friends’ friends. My friends are difficult to mock, therefore mocking sucks…

… well, yeah!

Testing procedural code is hard. Testing such code generally involves setting up “data” and asserting on state of objects. Tell Don’t Ask code on the other hand is easier to test since you’re not testing state. Also notice how DI makes things simpler to test.

void testOwnerCanFeedDog(){
    Dog dog = new Dog();
    // have to create a mouth since owner calls dog.getMouth() to feed it
    Mouth mouth = new Mouth();
    dog.setMouth(mouth);
    PetOwner owner = new PetOwner();
    owner.setDog(dog);
    owner.feedDog(food);

    // verify that the dog gets the food (well the mouth, actually)
    assertEquals(food, mouth.getFood());
}

void testOwnerCanFeedDog(){
    Dog dog = mock(Dog.class);
    PetOwner owner = new PetOwner(dog);
    owner.feed(food);

    // verify that the dog gets the food
    verify(dog).feed(food);
}

Without Dependency Injection, testing is quite difficult; without Tell Don’t Ask, testing is almost always impossible. Put together, things are separated, testing is simplified.

I spend more time reading code than writing it. I therefore like code that is readable. Rarely do I like to read code that is verbose and does too much orchestration in order to do something that is orthognal to what I’m looking for.

Code is easier to read and maintain when objects are written in a Tell Don’t Ask.

“Tell, Don’t Ask” is a style of programming where anObject tells anotherObject to doSomething(), rather than asking anotherObject to getSomeValue() and then makeADecision().

Code that does violates this this is more procedural than it is object oriented. In the procedural world code is written to fetch some data (or state) and then make a decision or perform some action. Procedural programming “pulls data” into the logic to get things done.

In object oriented programming, we do the opposite — have objects do something for you instead of you doing it yourself. Don’t overdo this too much, someone still has to do the real work though

Identifying places where you may tell instead of ask:

class PetOwner{
    void feedDog(Food food){
        if(getDog().isHungry()){
            dog.getMouth().putFood(food);
        }
    }
}

This can instead be written as:

class PetOwner{
    void feedDog(Food food){
        dog.feed(food);
    }
}

class Dog{
    void feed(Food food){
        if (iAmHungry()){
            // consume food
        }
    }
}

Notice how the PetOwner does not know (or care to know) about the fact that the dog has a mouth.

I am often asked this rather perilous question:

How do I view code coverage for my functional tests?

Short answer:

Here’s how…. However, use it only for figuring out what functionality is not covered, not as a workaround for not having enough unit and integrations.

Having to use functional tests to determine percentage of code coverage is IMO a bad smell, avoid as much as possible.