Suppose middle earth wants to keep track of the dragons that were slain over the centuries. The dragons are tracked in one list, and reports come in from different dwarfs, humans or elves. Sometimes, a dragon was reported slain falsely, so it needs to be removed.

A test for this list could look like this:

public class SlainDragonsTest {
 
    private final SlainDragons uut = new SlainDragons(); 
 
    @Test
    public void shouldSafelyAddAndRemove() throws Exception {
        uut.addSlain("Scatha");
        uut.addSlain("Smaug");
        uut.addSlain("Glaurung");
        uut.removeSlain("Smaug");
        assertThat(uut.getSlainDragons(), hasItem("Glaurung"));
        assertThat(uut.getSlainDragons(), not(hasItem("Smaug")));
    }
}

After a battle, lots of reports tend to come in at the same time, so the list has to work under stressful conditions without errors. So, we want the test to be executed simultaneously by a large number of threads. Each of the threads has to pass and the collective result decides on the JUnit report. For this purpose I wrote a “Manifold” class that converts the test to a load test.

  @Rule public Manifold simultanousReports = new Manifold(200);

Internally, Manifold opens 200 threads and runs the test method simultaneously inside the thread. It waits for all of the threads to finish and fails with the first error it found. No further adjustment of the test methods is necessary. If you are interested, you can download the class Manifold here.

Happy dragon hunting!

Who would not want to be part of such a movement? – So now we are a community of professionals who value well-crafted software (BINGO again). And the first time after reading Robert Martins books you’ll have some clear impressions that tests are the one thing that make the difference. Everything else follows – eventually even the understanding what kind of tests the dear uncle is talking about.

The manifestos are referred to often enough, and I’m sure you are at least somewhat familiar with them. Still I want to repeat them again, but to not get boring, let me combine them to make it clear that one Manifesto is the extension of the other.

• We find working software more important than comprehensive documentation. In pursuit of this, we also practice crafting software well and and help others in doing so.
• We find individuals and interactions more important than processes and tools. In pursuit of this, we form  a community of professionals and invite others joining in.
• We find customer collaboration more important than contract negotiation. In pursuit of this, we find productive partnerships indispensible.
• We find responding to change more important than following a plan. In pursuit of this, we strive for steadily adding value.

The Agile Manifesto and the Software Craftsmanship Manifesto are quite concise and carry a lot of values. Together they provide a high standard anyone involved in Software Development can adhere to. I find that many developers who follow the craftsmanship movement focus too tightly on the italic part.

It’s important to note that the Agile Manifesto gives priorities. It states that working software is valued higher than comprehensive documentation. However, the Software Craftsmanship manifesto is an addition. It reads “but also well-crafted software”. Where the Agile Manifesto used the word “over” to tie the right and the left side of the priorities together, the Software Craftsmanship Manifesto uses a “but also“. Well-crafted software means nothing if it is not the working software that the customer wants.

So remember, before you raise the bar, make sure you jumped over it at least once before.

The path you choose to take depends on the type of artifacts at hand. There are two types of Eclipse directories: The Repository format and the Runnable format. These are identified by the plugins/ and features/ subfolders)

• Repository format: The features and plug-ins are jar’d, maybe gziped, and could possibly be in the .blobstore. The repository format is read by the Software Site-type target definition entries.
• Runnable format: The files and folders in plugins/ and features/ are ready to be consumed by a running instance of Eclipse. The Directory type target definition entries use the runnable format.

Undoubtedly, in the case of projects that should go on top of Eclipse, the Software Site is the correct choice. This gives projects the option of consuming p2-directories directly from the source. For example, you can enter any of the Eclipse Project Update Sites.

The problem with Software Sites is that a project relative-location is not possible. This means that if you want to keep your target platform contained in one location, and possibly independent from Internet access, then Directory entries are the way to go.

In some cases, the target platform will be in a repository format, but you actually want to consume it in a runnable format. For example, PDE can only consume the runnable format. You typically notice that something is amiss when PDE does not see the features that are jar’d in the features/ folder.
There are several ways to transform the repository formats, but none of them are obvious. The simplest one I know is to create a throwaway target definition that points to the (possibly local) software site.

Then I use the Export Target Definition wizard to export all referenced features and plug-ins into runnable format.

The exported folder can then be copied to the final location and referenced by a Directory style entry.

How do you transform p2-repositories into runnable format?

• Acceptance test
• Integration test
• System test
• Component test

Image via CC BY-SA 2.0 from Dave Heuts

Once you have done this, you have an idea why the world is in utter need of a common test language. The problem is a lack of definitions but rather the big variety of similar or competing definitions on the one hand, and as a result the missing motivation in looking up any of them on the other hand.

The ISTQB is a not-for-profit organization that works on advancing the software testing profession. It managed to define a glossary on terms needed in software testing that was authored and thus accepted by a large number of professionals from many different countries. The glossary is in the version 2.2 at the date of writing this with the latest update in October 2012. The knowledge of it’s existence is not wide spread which is a pity because this is a quite useful reference document.

To give some examples, this glossary defines integration testing as “Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.” By itself this does not have too much meaning, and rightfully so, since this term is used so vaguely in the industry. But the glossary goes on to also list integration testing in the small (“see component integration testing”) and integration testing in the large (“see system integration testing“), and now people can speak meaningful to each other again.

To me a minor surprise was the equality of component and unit. According to the glossary a unit test is a component test and vice versa. In both cases it applies to the “Minimal software item that can be tested in isolation”. I suspect that projects that work with different abstraction layers of components (such as Class and Bundle) need a more detailed definition. But such differentiation can not be covered by such a general document.
A quite useful definition is given for functional testing as “Testing based on an analysis of the specification […]” and references to black box testing.

This glossary it worth some glances and to be kept close. In the next discussion about the details in testing, bring it along and spread the word. The industry will be able to move faster with a common understanding of testing terms.

Do you know other testing glossaries that might compete with this one that lists 57 authors from 15 countries?

• Open the “Problems” view menu by clicking on the little triangle in the upper right corner of the view. Select “New Problems View”.

• Choose a suitable name. This view only shows the errors in my current editor, so I enter “Error Outline”.

• Place the “Error Outline” under the Outline.
• In the “Error Outline”, open the view menu. Select “Configure Contents”.

• The configuration dialog is fairly straight-forward. Configure it to show Errors/Warnings on Selection and it’s children as shown here.

Now you have a fully configured Error Outline that shows a list of the current problems in your Editor.

By the way, you can also move through the problems in your editor by keeping your CTRL key pressed and hitting ‘.’ and ‘,’.

I find it useful to have 2 Problem views configured, one that focuses on the editor and one that shows me the problems in my project. The workbench layout is then shown in the following picture.

Happy X-Mas

• Allow functional testing of RAP/RWT applications.
• Allow stress testing of RAP/RWT applications, working together with a performance test library.

A secondary requirement is to:

• Be similar enough to the SWTBot API so that the effort for testing single-sourced applications is minimal

which gives this project the name RWTBot.

The following example test connects to the RWT Controls Demo and tests the toggle button functionality:

@Test
public void selectToggleButton() throws Exception {
  String rwtAppUrl = "http://rap.eclipsesource.com/controlsdemo/controls";
  RWTBot bot = new RWTBot(new RWTBotClientParameters(rwtAppUrl));
  RWTBotDisplay session = bot.startSession(); // 1. handshake
  RWTBotShell shell = session.shell(); // 2. identify the main window
  RWTBotButton observed = shell.button("Toggle"); // 3. Find a button named "Toggle"
  assertFalse(observed.getSelection()); // 4. check precondition
 
  shell.button("Toggle Button").click(); // 5. trigger UI change
 
  assertTrue(observed.getSelection()); // 6. check post condition
}

During the test, this happens inside RWTBot:

1. The initial handshake is executed with the RWT Demo. This opens a RAP session and a display is created. All widgets on the main screen are received. RWTBot control handlers for roughly 100 controls are created and configured.
2. Initially there is just the main window. This is identified and the RWTBot handle is received.
3. The main window has a button named “Toggle”. A handle for the button is received and remembered as a local variable. It will reflect the state change in the UI.
4. Assert that the precondition is as expected, ie. that the toggle button is deselected.
5. The “Toggle Button” is clicked. This is sent to the server which responds with changes for the UI. These changes include the activation of the observed button.
6. Assert that the postcondition is as expected, ie. that the toggle button is activated.

Did I miss any design criteria for RWTBot? Are you interested in a working RWTBot? Leave a comment or email me to let us know.

Via Creative Commons from dybarber

Developer documentation, if available, is a great thing. It is even better if you can actually find the piece of information you are looking for. Most documentation I have seen is organized in one big hierarchical tree. It’s impossible to find anything until you have intimate knowledge of the tree itself. The problem is often that the information itself is not structured enough to naturally fit in a single hierarchical tree, but it is pressed into it because it appears to be the only way to structure things.

The idea that information is best structured in single-dimensional hierarchies comes from a world where it was expensive to store objects in more than one place. Everything that is paper-based or contains other physical entities belongs in this category. Unfortunately, this idea has been burned rather strongly into the post-modern human brain, and only slowly are people realizing that this is an artificial border that is no longer relevant in the information age. In my last blog entry 10 Principles on Electronic self-management I roughly outlined the archive. Here I want to elaborate and generalize this idea.

Labels deal with unstructured information

Many applications nowadays allow their documents to apply labels, sometimes called tags.

Labels have simple characteristics:

• A page/document can have multiple labels
• Multiple pages/documents can have the same labels
• You can browse by labels, or sometimes search for them

For creating a label-based archive your application needs another feature:

• Browse combined tags, i.e. find all documents that have both tags rap and osgi

This feature is available in applications like Evernote, Google mail and Confluence. Some systems that provide tag clouds are missing this feature, though.

Creating an effective archive with labels

A label-based archive works fine with mostly unstructured information like documentation snippets or notes, but for a better understanding we’ll start with something very structured. Consider a classical paper-based address book. All entries are organized alphabetically, but more importantly, they are organized by single letters.

• B – Steve Ballmer
• C – Tim Cook

Now let’s move this address book to the electronic world, and forget address book applications for the moment. Both “Steve Ballmer” and “Tim Cook” are documents now, and we can label them. “Steve Ballmer” gets a B, but because it’s convenient he also gets an S. “Tim Cook” gets C and T.

• Steve Ballmer – B, S
• Tim Cook – T, C

When your address book grows, and you have 50 or more entries under B, it will still be easy to find Steve Ballmer, because the combination of S and B will remain rare. Not unique, but rare enough.

This approach alone is rather powerful, so it’s tempting to move other things to this document database. Let’s organize bookmarks, too. But wait a moment. Before you start labeling “Steve Ballmers Blog” with S and B, it’s time to categorize address book entries by adding the label addressbook.

• Steve Ballmer – B, S, addressbook
  
• Tim Cook – T, C, addressbook

Now you can add your bookmarks.

•     Steve Ballmers Blog – B, S, bookmarks
•     Tim Cooks Blog – T, C, B, bookmarks

Applying labels to somewhat structured information

Look at the hierarchical tree on the left. Imagine that this tree names only the folders, and each folder contains one or more documents with the actual information. It is a small but quite typical tree in any wiki of any mid-sized development project.

Let’s see how we can add labels to the documents in that tree. It appears obvious that client, server and database get their own categories. A document “Installing the client on Linux” gets the labels client, I, L. Also, if supported systems include Ubuntu and Redhat, the labels U and R are added.

faq is also a strong candidate for its own category label. After careful examination the team might decide that the installation and uninstallation topics are addressed well enough by I and U. Also, the homeless document that hides under “Server Migration” might get the labels server and M.

Should the team feel that migration is almost worth its own category, but does not want to commit to it, it’s a good idea to label the documents in question with both migration and M.

I use this archiving method for 500+ documents and generally find what I want with at most 3 intersecting tags. I don’t see any scaling issues for the next few hundred documents. What comes after that?

I myself will share a success story of an in-house development project we have had now for a couple of years. My talk lines out the tools we use during development, for Continuous Integration, how the process works and fits together with the contracts. I will talk about team spirit and fluctuation and adjustment to change.

Go here  to see what other talks there are and register now for the Eclipse Day in Delft.

Why electronic?

Pen-and paper-based self-management systems can be quite effective if they fit in your life. That may be the case if you spend the major part of your day in meetings or in the woods.
I sit most of my work time in front of a computer. A part of the stuff that comes into my inboxes is in electronic form, like emails or URLs. A part of my things comes from the real world in the form of spoken words or business cards or the like.
I found it rather cumbersome to hand-copy a URL to a paper (and back, when I need it), but quite simple to take a photo of a business card, so I switched to a complete electronic system a couple of years ago. This raises the question of platforms and programs and how to use them. This is what I want to discuss in this blog post.

I will start with an overview of methodologies. Many people are not happy with Getting Things Done (GTD), because they regard it as too complex for some of their needs and they find it does not solve others. I will give you some hints what else there is, and how all that can fit together and scale to your needs.

In my opinion the program itself is not so important as how you use it. I will name a few programs I worked with or had a look at, but leave the decision which one to use up to you.

Methodologies

Principle: Just be done with it

The best thing to deal with an upcoming item is to be done with it right away. If it does not distract you. Got your tax refund notification, and it looks ok? Put it in its folder (not on the kitchen table). Got a strange request from a user of your application that does not fit in any plan? Just forget it.

Principle: Stay focused

Most things are not so easily dealt with. They need action on your side, and when you are already focusing on a piece of code there is no way you can deal with this new feature request now. But you need to remember it, so your action is to put it in the inbox.

Principle: Keep everything together

Getting Things Done (GTD) is the most prominent and most often cited self-management system. It also seems to polarize people, having both ardent fans and harsh critics of it being overblown.
As many people I find it crucial to get things done rather than organizing them, and I found that GTD allows to spend a lot of time organizing, if used without focus.

People who start out with the good intent of getting themselves organized often try to do it all at once, and then drown in the number of possible management actions. In the Dreyfus model they are Novices for self-management. They would need somebody telling them the next step or the bigger picture, but self-management is rarely taught, only expected. Novices who don’t get the ‘why’ dismiss methodologies like GTD as overblown.

Self-management is a habit. Habits are not changed easily, so if you have a good intent now, start out slowly.
Try Zen To Done, it’s a nice write-up that specifically wants not to be read all at once but only when you are ready for it.
Regard it as a toolbox, and scale it to your needs. Other toolboxes are also available that allow you to mix your own self-management system. I personally found the ideas in Steven Covey’s “7 Habits of highly effective people” rather convincing and put them into my own mix with GTD.

Principle: Pick the Right Next Action or Swim Through the Activity Stream

It is in the nature of a management methodology to talk about the management of the things. This is sad considering that it’s purpose is to get stuff done. In your day-to-day life the actual doing should be in the foreground. Your self-management should provide you with the next action. It should filter out distractions and point you to the next most important and most urgent action. Ideally it provides you with an Activity Stream that you can follow through.

The Activity Stream is the list of actionable items you could pick next. It changes with your location, present coworkers, available time and motivation.
My Activity Stream comes from the Next Actions of GTD, where things are associated with a certain context, say Office, Home or Computer. But I enhance it with priorities, estimated times, and sometimes mood. I can narrow the Activity Stream down or widen it as I find it useful at any given moment.

When you have your activity stream set up, use a time boxing technique like Pomodoro to work through it.

Sometimes the number of actionable items in a context feels overwhelming. This is the time when prioritizing comes into play. Consider using the 4 quadrant method that divides things by urgency and importance. A good help in the distinction between important and not important is the question “Do I want to I live with the consequences of not doing it?” This distinction is also useful when processing the inbox to decide which things to trash immediately.

When working with the 4 quadrants for a while, you will see things more often in Priority 2 than Priority 1. When there are many in Priority 2, you can do 2 things:

1. Set a reminder to a date when a thing becomes urgent, and thus Priority 1.
2. Attach an estimated duration (this also helps when you drown in Priority 1).

I use 3 estimated durations:

• <10 minutes. This is something too large to do during processing the inbox, but not too time-consuming either. Most email answers are here.
• <25 minutes, 25 minutes is my time box for a Pomodoro. So an item <25 minutes is a thing I process in one Pomodoro.
• <60 minutes. Something bigger. When I think it takes longer than an hour, I split it up or reconsider putting it in the Activity Stream. A calendar entry might be more useful then.

With priorities and estimated duration I have a pretty good overview of the time I will be busy and am able to pick a kind of work I can do right now. I set up a tag hierarchy Activity Stream in Evernote with tags for priorities and duration. This helps me find the next thing to work at.

Sometimes my mood catapults me out of the normal work flow. I use a special tag in the Activity Stream that points me to the next thing to learn when I’m curious, warns me of not acting regrettably fast when I’m upset and helps me find funny videos when I’m down.

Processing things

Principle: Use a Mobile Inbox

The most important thing for any self-organization system is a mobile inbox. It’s the thing where you dump ideas that hit you while you are biking or hiking, where you note down distractions when you focus or just are trying to remember a name, address, date or whatever else.

For electronic systems a mobile inbox means almost certainly you own a smartphone or another PDA like the iPod touch. In the Google Play Store or the Apple App Store numerous applications promise to capture any text, picture or sound on a whim.
I find a one-click-action important that leads to whatever way I want to input, like the Evernote Widget on Android.
At the moment the strongest players in the field are Evernote and Springpad.

Principle: Have a well-integrated stationary Inbox

But the mobile inbox is only half the inbox. When working on your desktop you also need a good application for collecting upcoming ideas. A lot of input arrives from different directions that needs to be put away fast without distraction. The perfect stationary inbox allows you to reference into other programs.
For example the Mac Application Things allows you to reference emails in the Apple Mail or files on the file system. This makes it perfect for being the central application in your work that spawns all other actions.

Your Email inbox is a natural part of your inboxes. During planning, regard emails as any other thing in the inbox(es), this means

• If you do not need to do anything, move it either to the trash or the archive.
• If something needs to be done, and it takes less than 2 minutes, do it immediately. Then move the email out of the inbox.
• If something needs to be done that takes a while, convert it into an actionable item. Then move it out of the inbox.

Make sure you use a system where your actionable items can contain a reference to your email. Decent Webmailers will provide a static link for each email that you can include in your list of actionable items.

The Evernote Webclipper can convert a URL into a note that you can use as your actionable item with very little effort.

Principle: Organize with tags

Most serious note-taking applications offer you two ways to organize notes: folders and tags (sometimes called labels).
A note can only be in one folder, but can have multiple tags. Thus I find tags a lot more useful and use folders only when I must due to technical reasons, i.e. for sharing with others.

You saw an example of tag using in the Activity Stream, here is another one:
I have an archive with every letter of the alphabet. When I decide to archive a thing, I put in multiple letters for every way I can think of to approach it. So when I look for an URL about Getting Things Done I will select the letters one by one. Each filters out more notes until I find the link where I took the idea from. This approach for archiving notes scales very well.

My blog post Creating an effective archive with labels elaborates this idea in more detail.

Reminders

Principle: Use reliable time based reminders

A time-based reminder gets back to you at a set date. I use time based reminders for every follow-up. When I write an email asking a question, I set a date when I want to re-ask if I did not receive the answer. When my Priority 2 seems so full that it’s unclear when I can work through it, I set dates to make the items urgent. Ideally you see your time-based reminders high in the Activity Stream, but this is only possible when your application supports this. Things and Springpad are candidates.

Evernote is often criticized for not supporting time based reminders. In that case, you can easily use a calendar as a replacement. If your calendar application supports multiple calendars, keep a separate calendar for your time-based reminders. This allows you to separate your actual appointments from things you just want to remind yourself of.

The Google calendar also provides the Google Tasks API which allows you to set dates to tasks. Special applications in the Play Store have widgets to display the upcoming (or past) tasks on your smartphone’s screen.
When setting an external reminder, I generally use copy & paste of my notes title in the calendar entry. This allows me to easily find the note when I was reminded of it.

Principle: Have a clear view on your Agenda

Your Agenda outlines your day. Appointments are there and things you need to do today. The agenda sometimes shapes the Activity Stream, but often leaves room to follow it through more generally.

I use a calendar widget and a Google tasks widget on my phone’s screen for displaying today’s agenda.

At the end of the day I like to have an overview about how much of the Agenda I worked through. I have yet to find a widget that turns my Google calendar events into checkable items and integrates the Google Tasks. If you know such a thing, please leave a comment.

Principle: Practical location based reminders

An unfulfilled promise is the dream of your cell phone reminding you to buy milk when you are in the store. Yes, there are dozens of applications out there promising location based reminders, yet all have one problem: They need the location service of your phone turned on and will cut down your battery life approximately by half. Considering that many of today’s Smartphones already have a tough job running throughout the day, this makes location based reminders highly impractical as part of a system.

If you have a setup where you actually use location based reminders as part of your daily life, please leave a comment about the details.