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

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.

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.

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.

Mariot Chauvin recently polished the initial contribution from David Green and released a version 0.1 of the gef support. We’re working towards integrating this as part of swtbot and you should hear more about it once the IP process is done

In this regard the users of swtbot are a bit special. Most of them understand testing and the principles associated with testing but do not necessarily understand swt, threading models and the workbench and platform internals. Getting such users to use eclipse, create test plugins and write tests in java involves more than just documentation and screenshots.

Mohammed recently posted two such 5 minute videos. Getting started with swtbot in under 5 minutes, and run your UI tests in a headless build from within ant.

A video is worth a thousand images

He compiles Mozilla on Opensolaris during nights, and has recently been working on getting SWT/Mozilla to work on OpenSolaris-gtk. He aims to eventually contribute eclipse builds for opensolaris. This would also get a lot og SWT based apps like the Google Web Toolkit(GWT) to work on OpenSolaris

You can catch up with him at JavaOne and the Eclipse Party at JavaOne.

Sriram lives here.