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

I just realized that I had about 58 eclipse SDKs downloaded on my hard drive and 22 instances of different versions of eclipse. That was a whooping 9GB for the sdk downloads and 6.5GB for the extracted versions. Time to move to newer dope

Similar was the case on the cruise based build grid that tested SWTBot from all versions starting from eclipse 3.2 upwards to the latest RC build on all platforms — linux-gtk/linux-gtk-64/win32/macosx-carbon.

Eclipsetasy

An Eclipse DemoCamp is a congregation of Eclipse enthusiasts to meet up and demo what they are doing with Eclipse. The demos can be of research projects, Eclipse open source projects, applications based on Eclipse, commercial products using Eclipse or whatever you think might be of interest to the attendees. The only stipulation is that it must be Eclipse related.

Earlier you’d go get a coffee every time you clicked the eclipse update manager. With the eclipse servers taking a beating and download speeds really going slow you better grab lunch.

But wait there’s another nifty “hack”: Don’t talk to the eclipse servers.

To make the p2 update manager faster (assuming you aren’t downloading from the eclipse mirror sites):

• Edit your hosts file (/etc/hosts or c:\windows\system32\drivers\etc\hosts)
• Add a fake alias for the download server:

  127.0.0.10 download.eclipse.org
  

Open the update manager again, enjoy the amazing speeds, remember to remove the line if you indeed want to talk to the eclipse servers.

A listing of some of the new features available:

Bug 263036 – SWTBot finally has an icon that was missing since two years!
Bug 269919 – Added support for toggle buttons
Bug 271246 – Better support for handling editors. This should serve as a good start towards providing support for multipage, forms based editors
Bug 271132 – Using Display#post() to support sending native click events instead of fake events. This is still work in progress and not all widgets support native events yet.
Bug 273624 – Use native keyboard events for typing. SWTBot currently defaults to using AWT robot. SWT’s Dispay#post() is available as well — it is however buggy across platforms and swt versions. Since SWTBot uses native keyboard events, it needs to understand various Keyboard Layouts.
Bug 267189 – Support capturing screenshots of widgets.
Bug 277093 – Support for Link widgets.

There are also a lot of minor bugs that were fixed in this release.