Bertrand Meyer, ETM, Java Byte Code, Eiffel

Bertrand Meyer is the author of a classic software development book Object-Oriented Software Construction.  He is also the father of the Eiffel language.  I have a lot of respect for his work, it was quite heavily plugged when I was at Monash.

In looking for a Bertrand Meyer home page, I came across Betrand Meyer’s ETM homepage.  ETM is where he was working during mid 2007 when the page was written.  He plays a part in co-teaching many of the subjects there (lucky students!).

There are many pieces of gold linked to his site, though these two subjects seemed of most interest to me.

+ “Languages in Depth” series: Java programming, with Manuel Oriol (bachelor’s/master’s) Java

The lectures about the class loading and bytecode were very informative.

+ “Languages in Depth” series: C# programming, with Lisa (Ling) Liu (bachelor’s/master’s) C#

You can also find a link the ECMA Eiffel language specification.

In addition, there are a few interesting tools linked to from this page, as well as a few from the Dept of Computer Sciences download page.

Autotest is a tool that generates tests automatically by looking at the source code, in particular, the way that Design by Contract is used, gives a lot away about what a human tester would be writing, but also tries to make up for the shortfalls that would not normally be apparent in the source code and the fact that developers aren’t perfect to begin with.

The text for the next lot appears directly from the school’s download page.

Contract Wizard 3.0
Description: Regrettably Design by Contract is still a specificity of the Eiffel programming language. Contract Wizard 3.0 is a GUI application that enables adding contracts (preconditions, postconditions, and class invariants) to any .NET assembly, whatever .NET language it was initially written in.

The Pattern Library contains patterns that are usable as components. For the patterns that could not be turned into components the download contains the Pattern Wizard, that let’s you generate the patterns according to your input.

Eiffel library to generate Java bytecodes

Description: This Eiffel library is able to generate Java class files that can be executed by a Java Virtual Machine. A simple language with a corresponding compiler that uses the library as backend was created to test this library and also to give examples of how to use the framework. This language is similar to the Java language, but much simpler.

Funnily enough, the java references I mention in this blog all make reference to the following sites:

The universe is telling to learn about the bytecode behind the JVM…  javap My.class

UML and CRC and Agile References

CRC Cards (Class Responsibility Collaborator cards)

Class Name
Responsibilities Collaborators

A very good UML diagram reference (I may have referenced this one before).

http://www.agilemodeling.com/essays/umlDiagrams.htm

And a page of useful agile resources, from a process standpoint.

http://www.agilelogic.com/sp_resources.html

I particularly like the ones about Missing the Point of the Daily Stand-Up? and eXtreme Adoption eXperiences of a B2B Start Up

The Self-Shunt unit testing pattern in short is a way to think about your tests so that you are not testing more than one thing in a test. It talks about passing the object you are testing to itself. Here is a quote (paraphrased) from the document about when to use it "Methods such as testScanAndDisplay scream testing two things."

RSA Client Downloads

RSA clients for windows from 5.2 -> 7.0

Both 64 bit and 32 bit versions.

Am using the remote agent with 6.1 on Vista Ultimate and everything is hunky dory.

What prompted me to upgrade was a recent Vista SP1 upgrade and some strange behaviour afterwards.  Some connections would cause the authentication process to lockup and a particular Windows service to fail.

https://www.rsa.com/node.aspx?id=2518

More on Enums

Something that bothers me about Java Enums, is that they don’t represent ints out of the box.  Like no easy way to use them to represent particular indexes in an array, with the auto-incrementing thing happening, as per C/C++.

If you look a little deeper, there is the YOUR_ENUM.ordinal() method which will give you an int based on the position in your code that the ENUM_USED appears in the enum class, but the javadoc for ordinal makes you wary about using it

Returns the ordinal of this enumeration constant (its position in its enum declaration, where the initial constant is assigned an ordinal of zero). Most programmers will have no use for this method. It is designed for use by sophisticated enum-based data structures, such as java.util.EnumSet and java.util.EnumMap.

Returns:
the ordinal of this enumeration constant

"Most programmers have no use for this method"…. This method emulates the old C way of doing enums and not specifying a default.  Surely many programmers would be at home with such a thing?

…. is there a better way to represent static constants of indexes that don’t use an enum?

Well, there are some articles on this question, and what exactly the java enum implementation can and can’t do.

Making the Most of Java 5.0: Enum Tricks

This article contains some really clever things you can do with Java enums, like having a static block in the enum to initialise a static Map or even cooler, using Enums to implement Template methods.

AssumeThat(flexibleJunitTesting.withMatchers(), isGreat());

I’ve seen Matchers used in EasyMock but I kinda stumbled across the assertThat method in JUnit today and realised how powerful this stuff can be.

Usage:
assertThat(“You Failed”, testValue, allOff(greaterThan(3), lessThan(6))

They seem a lot simpler in this context even though they are the same thing.

The Matchers are taken from a project called Hamcrest which both JUnit, various xMock and other testing frameworks have all jumped on board to.

Hamcrest comes with a library of useful matchers. Here are some of the most important ones.

  • Core
    • anything – always matches, useful if you don’t care what the object under test is
    • describedAs – decorator to adding custom failure description
    • is – decorator to improve readability – see “Sugar”, below
  • Logical
    • allOf – matches if all matchers match, short circuits (like Java &&)
    • anyOf – matches if any matchers match, short circuits (like Java ||)
    • not – matches if the wrapped matcher doesn’t match and vice versa
  • Object
    • equalTo – test object equality using Object.equals
    • hasToString – test Object.toString
    • instanceOf, isCompatibleType – test type
    • notNullValue, nullValue – test for null
    • sameInstance – test object identity
  • Beans
    • hasProperty – test JavaBeans properties
  • Collections
    • array – test an array’s elements against an array of matchers
    • hasEntry, hasKey, hasValue – test a map contains an entry, key or value
    • hasItem, hasItems – test a collection contains elements
    • hasItemInArray – test an array contains an element
  • Number
    • closeTo – test floating point values are close to a given value
    • greaterThan, greaterThanOrEqualTo, lessThan, lessThanOrEqualTo – test ordering
  • Text
    • equalToIgnoringCase – test string equality ignoring case
    • equalToIgnoringWhiteSpace – test string equality ignoring differences in runs of whitespace
    • containsString, endsWith, startsWith – test string matching

Here is a summary of Matchers from the Hamcrest tutorial page.  They may not all be in JUnit.  JUnit ships with org.hamcrest.CoreMatchers and org.junit.matchers.JUnitMatchers.

Assumptions

Assumptions are like @Ignore-ing tests programmatically.  They are a test, intended to determine that the environment a test is running in, will successfully run the test.  The example from the JUnit 4.4 release notes best illustrates this:

import static org.junit.Assume.*  
@Test public void filenameIncludesUsername() {
assumeThat(File.separatorChar, is('/'));
assertThat(new User("optimus").configFileName(),
is("configfiles/optimus.cfg"));
}

If the expression in the assume statement fails, then the test will be marked as passed.  Apparently in future, the failed assumption may lead to the test being marked as ignored which would be excellent.

Edit: Another useful resource is the Junit API on Matchers