Chapter 15. Failed Tests Are Compile Errors

Now we come to what passes for a dramatic plot twist in the story of a software project. We thought of ten or twenty features we could add to our JUnit view: progress bars, hierarchical test suite browsers, and on and on. However, something was missing—rhythm. Intimately interleaving testing and programming has a whole different rhythm than programming for a while, then testing for a while. The difference is much the same as the difference between an incremental compiler that runs all the time and a batch compiler that takes long enough to drink a café macchiato.

*Bing,* the light bulb lit. What if failed tests were treated just like compile errors? Every time we make a change to the source, the tests will be run. Any failing test will result in a marker just like the markers the compiler creates when it detects a syntax error. We'll use the same mechanisms to navigate semantic errors (failing tests) that we use to navigate compile errors.

We've seen this pattern repeated in Eclipse. At first a tool comes into Eclipse as a separate thing—view, editor, or even a separate perspective. With experience, though, you begin to see how the new functionality is really a variant of the existing functionality in Eclipse. By looking at your idea using the existing metaphors in Eclipse, you can make the user's experience of your tool less like a new thing to learn and more like a better Eclipse.

When you let a drop of blue paint fall into water, it is clear at first where the paint is and where the water is. Over time, though, the paint disperses and the boundary blurs. Wait long enough and you just have water that's now a little blue. It is so with contributions.

  • INTEGRATION RULE. Integrate, don't separate.

Markers and Resources

Resources are the Eclipse-internal representation of resources like files and folders. Projects are also resources, a folder with additional attributes that allow the contents to be built.

Markers are general-purpose annotations on resources. Any resource can have markers attached. Markers also have an open-ended set of attributes. By convention, sets of attributes are used to describe common markers like compile errors. Attributes are also used to indicate the marker location inside of, for instance, a text file. The type attribute and the marker extension point are used to group markers in a lattice. By making your marker a sub-type of an existing marker, your marker should work anywhere the existing marker works.

Markers are also used to note tasks to do, breakpoints, bookmarks, and search results. Markers appear in the task list, in special purpose views like the bookmarks view, and the margins of text editors. Markers are useful any time you want to provide feedback in the context of a particular resource.

Scalability comes into play with the Integration Rule. Imagine we have thousands of contributions. If each of them comes with their own pet mechanism, you have thousands of mechanisms and a big mess. By reusing the existing metaphors and extension points, you increase the value of your contribution. Blurring the boundaries between contributions gives the user the experience of a single tool.

We will implement our new “failed tests are compile errors” metaphor in steps:

  1. Each time tests are run, we will turn failed tests into markers.

  2. We will attach a property to a project to decide whether tests should run automatically.

  3. We will install the test-run builder when the property is set.

  4. We will automatically find the tests in a project.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset