We are proud to announce that FEST-Assert 1.3 is out!

FEST-Assert is an “assertThat” library that provides a fluent interface for writing assertions. Its main goal is to improve test code readability and make maintenance of tests easier.

Example:

int removed = employees.removeFired();
assertThat(removed).isZero();
 
List newEmployees = employees.hired(TODAY);
assertThat(newEmployees).hasSize(6)
                        .contains(frodo, sam);
 
String[] newHires = employees.newHiresNames();
assertThat(newHires).containsOnly("Gandalf", "Arwen", "Gimli"); 
 
assertThat(yoda).isInstanceOf(Jedi.class)
                .isEqualTo(foundJedi)
                .isNotEqualTo(foundSith);

Release notes

Bug

• [FEST-133] – DoubleAssert.isEqualTo() behaviour change? Many thanks to Stanislaw Osinski.
• [FEST-307] – assertThat(Integer) automatically unboxes Integers and returns IntAssert. Many thanks to Tomasz Nurkiewicz.
• [FEST-329] – MapAssert#containsEntry doesn't actually assert the entry exists. Many thanks to Mark Derricut.
• [FEST-367] – ListAssert should support duplicates in method 'containsOnly()'.

Improvement

• [FEST-171] – Add method isEqualToIgnoringCase to class StringAssert.
• [FEST-197] – Add isNull, isNotNull to all Assert classes taking wrappers of primitive types as 'actual' value.
• [FEST-259] – Adding error log functionality: extending the current as(…) method..
• [FEST-260] – Using Generic parameter in the super Assert classes such that many code can be moved up and remove in de sub classes. Many thanks to Ed Bras.
• [FEST-261] – Make BasicDescription non final. Many thanks to Ed Bras.
• [FEST-310] – Add isNotZero() assertion to BigDecimalAssert.
• [FEST-326] – Improve error messages related to unexpected null values.
• [FEST-334] – Iterables assertion support. Many thanks to James Ravn.

New Feature

• [FEST-252] – ignoringCase() feature for String assert
• [FEST-324] – Allow assertion on extracted values of a given property of collection/array elements
• [FEST-328] – assertThat(someString).doesNotContain("foo");

For more details about new, updated or removed classes, please read the change report.

You can download the latest release here (file fest-assert-1.3.zip.) FEST-Assert requires Java SE 5.0 or later.

Here are some useful links:

• Home Page
• Documentation (wiki)
• Changelog
• Javadocs
• Issues
• Users’ Group

Feedback is always appreciated :)

Share/Save

This is the best definition of code metrics I have found so far¹:

Code metrics is a set of software measures that provide developers better insight into the code they are developing. By taking advantage of code metrics, developers can understand which types and/or methods should be reworked or more thoroughly tested. Development teams can identify potential risks, understand the current state of a project, and track progress during software development.

The key here is, in my opinion, that the purpose of code metrics is to help developers understand where their code needs to be improved. Unfortunately, code metrics, like any tool, can be easily misused, doing more harm than good. Let’s take my favorite code metric, code coverage, as an example.

As I mentioned many times in this blog, I use code coverage tools to help me discover which parts of my code need more testing. I don’t care if my code coverage is 50, 80 or 90%. What I care about is that the most complex areas of my code are properly tested. As useful as code coverage is, it can also cause problems if misused or misunderstood. Here are some examples:

• Management mandates to have X% of code coverage.
  This is actually not so uncommon, based on stories from friends and my personal experience years ago in consulting. Upper management, without a clue about the health of the codebase, mandates that developers should reach X% of code coverage. Period. (It gets even better when there is a deadline for reaching such number!)

  In many cases, when the codebase was not designed with testability in mind, I’ve seen developers writing a lot of test cases, without any assertions! All the tests pass, and the code coverage goal is met. The result?

  1. developers wasted time and effort without adding any improvement to the codebase
  2. management got a false impression that the code base is in a somewhat healthy state

• Developers follow numbers blindly, without thinking about their meaning.
  It is too easy (in many cases, comfortable) for developers (including QA) to fall into this trap (I’m guilty of this too!) Common examples include:

  1. Tests suites containing only unit tests. We, developers, tend to avoid functional and integration tests because they usually run slower and need more work to write and set up. Unfortunately, unit tests only work based on developers’ assumptions, but do not test that the actual application, as a whole, works as expected in front of the user.
  2. The wrong perception that “more is better.” Probably this is normal human behavior: 50% code coverage must better than 10%, or even 0%. Actually, it all depends on the quality and types of tests. For example, having 50% of code coverage with tests that do not have any assertions is worse than having 0%, because it creates the illusion of a healthier code base. Another good example is my recent experience of having 100% code coverage…and faulty software!
  3. A single metric to rule them all. Having a high code coverage number does not imply that our test suite exercises all the possible testing scenarios: potential race conditions and all UI-interaction scenarios are good examples. Working towards achieving 100% code coverage can prevent us from seeing important areas that need to be tested. In addition, we should not focus on a single tool to determine the state of our code. Code coverage is just one of the many code metrics that we can (or must?) use to determine the health of our codebases.

• Useless metrics reports.
  Even though we have excellent code coverage tools like Cobertura, EMMA (both open source) and Clover (commercial,) I have seen custom code coverage tools built in-house. There are many reasons for this, like NIH or lack of support for a specific language (e.g. Scala) in existing tools. What surprises me the most is the amount of time and effort put into building a custom code coverage tool that, at the end, does not allow developers to drill-down to the most basic unit: a single line of code.

  A code coverage tool that reports that method “X” in class “Y” has 10% code coverage, without providing a way to go one or more levels deeper, makes it impossible to figure out where we should add or improve our tests. In my opinion, this is not only useless, but harmful as well: pointing out a problem without offering a way to find a solution is not constructive, and it can start a blaming game within an organization.

In conclusion, code coverage (and metrics in general) not only need to provide accurate measurements in order to be useful. They also need to empower developers with a way to analyze those results to the minimum detail, to help them decide where and how a codebase could be improved. At the same time, developers need to understand that targeting a fixed number blindly is not only a waste of time and effort, it can also create unrealistic perceptions about how healthy a codebase is.

What do you think? Feedback is always welcome :)

¹ MSDN. Code Metrics Values.

Share/Save

After a couple of hours of frustration, I finally found the solution in this post from Konstantin’s blog: Eclipse was not setting the flag -XX:MaxPermSize, due to the change of vendor, from Sun to Oracle, in JDK 1.6.0_21. This is a Windows-only issue. As Konstantin points out, the fix is simple: just add the missing flag (with the appropriate amount of memory) to the eclipse.ini file, just after the -vmvargs settings.

Here is my eclipse.ini:

-startup
plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100503
-product
org.eclipse.epp.package.java.product
-showsplash
org.eclipse.platform
--launcher.defaultAction
openFile
-vm
D:\Java\jdk1.6.0_21\bin\javaw.exe
-vmargs
-Xms512m
-Xmx1024m
-XX:MaxPermSize=256m

Setting -XX:MaxPermSize to 512m (as Konstantin suggests) didn’t work for me. On my machine, Eclipse can only run if I set that flag to 256m.

For more details, including the bug number related to this issue, please visit Konstantin’s blog.

Update: The nice folks from DZone have posted this entry at Javalobby. To my surprise, this post (actually the re-post) turned out to be relatively popular, with 32+ (up) votes and more than 5,000 reads. For a couple of days, it was at #3 and #2 on DZone’s “Top Links.” :)

I’m proud to announce the release of FEST’s JavaFX Compiler Maven plug-in 1.0b2!

The plug-in compiles JavaFX source and test files.

This release adds new, useful configuration options. The release was driven by Johannes Schneider‘s work, based on his needs for the JFXtras project. I’d also like to thank Thomas Butter for helping us improve the project.

Features

• Compiles JavaFX source and test files
• Does not require JavaFX distribution to be in a Maven repository (according to its license, only Oracle can distribute JavaFX)
• Does not require to list all JavaFX libraries as dependencies in your pom.xml

You can find an example on how to use it here.

Release Notes

• Added ‘testSourceDirectory’ option.
• Magic classpath extension (with JavaFX jars) made optional.
• Improved error messages for paths.
• Compiler argument added: -Xlint:unchecked.
• Skipping compilation for non-java projects (e.g. pom.)
• Added possibility to “override” Java classes with JavaFX classes.
• [FEST-369] – Allow setting of ‘memoryMaxSize’. Many thanks to Thomas Butter.

The FEST JavaFX Maven plugin can be obtained from our Maven Repository.

Links

• Documentation
• Change report
• Issues
• Users’ Group

Feedback is always appreciated :)

Share/Save

In my previous job, I spent a considerable amount of time interviewing candidates. After years of interviewing candidates, I finally realized that a candidate’s personality and attitude are as important as her technical skills. Even though I’m going to describe what may seem obvious to most of you, I’d like to share my short and limited experience interviewing candidates.

As we all know, making a decision about hiring or rejecting a candidate is very, very difficult. There is no clear “black and white,” and intuition is usually involved. Unfortunately, I was not aware of this when I started interviewing candidates. As a result of inexperience, I naively focused, almost exclusively, on the candidate’s technical skills.

In the first couple of years I rejected several candidates, mostly because of their poor performance when solving technical problems. At some point in that time frame, I was lucky enough to interview two great candidates, who later on became my co-workers and good friends. Because my interviewing skills at that time were not mature enough, I didn’t realize that I gave them “thumbs up” not only because of their great technical skills, but because they are nice guys with a very positive attitude.

It finally hit me when I interviewed a very interesting candidate. He solved the problems I presented in record time, with the cleanest solutions I’ve ever seen. For a moment I got really excited about the possibility of having this brilliant guy in team!

It was literally “for a moment,” a tiny and brief moment. As in any interview, I asked the candidate about any questions he might have. He asked questions about the position he was interviewing for, the team and the Bay area in general. I tried to answer his questions the best I could but he never let me finish any sentence. At the end, it seemed that he got bored: he simply cut me off by saying that “we could talk about it after he gets the job.”

The candidate was not only rude. To make things worse, he made sure we understand he has better problems to solve and he is looking for a job flexible enough to give him enough time to concentrate on his own stuff. What I understood instead is that even though his technical skills were excellent, I definitely didn’t want to work with him. For the record, it was an unanimous decision.

After that experience, it was a lot more clear to me what I needed to look for in a candidate: a developer with strong technical skills that I can get along with, an open-minded person and a team player.

Finally, a few weeks before I switched jobs, I got a chance to put my new perspective about interviewing into practice. The interview did not start that well: the candidate needed more hints than expected to solve the first problem, which I considered to be only a warm-up exercise.

I was tempted to think that his technical skills were not strong enough. Instead of jumping into conclusions, I decided to take a break and talk about his background. He was a very nice and polite gentleman. After talking for a few minutes, I realized he was the type of person that cares about doing his best everyday. From the conversation I could tell he was a developer passionate about technology, looking for opportunities to learn new stuff. The candidate was surprisingly humble too: he created and lead a popular and successful open source project! He didn’t say a word about it until I asked him about his hobbies! This guy, as a person and as a developer, was great!

I was glad we stopped and talked for a little bit. He turned out to be nervous! After our short chat, he was more relaxed and he just solved the rest of the problems flawlessly! I’m sure if I didn’t change my point of view about interviewing, I would have dismissed this terrific candidate after the first exercise!

Few days after the interview, I was very happy to hear he was going to get an offer! :)

In conclusion, my lack of experience led me to evaluate candidates based on their technical skills only. As I got more experienced interviewing, I realized that personality and attitude are as important as technical technical skills. These days, in order to make a decision, I ask myself if I’m going to feel comfortable working with a candidate in the same team. More specifically:

• Do we have compatible personalities and similar technical points of view?
• Did the candidate show me I can trust his judgement?
• Was it pleasant to discuss technical problems with the candidate, even if we didn’t agree?
• How did the candidate and I behave when we disagree?

What do you think? I’d love to hear your experience interviewing! :)

Update: The nice folks from DZone have posted this entry at Javalobby.

Share/Save

I’m proud and happy to announce that I joined the JavaFX Controls team!

This is an awesome opportunity. Even though JavaFX is a pretty nice technology and there is room for lots of cool things to do, what attracted me the most was the team itself. This is my first week and I’m enjoying so much working with Brian, Jasper, Jonathan, Richard and Stuart. Soon the rest of the team will come back from vacation, and I’ll be having even more fun for sure!

I’m very grateful and fortunate to be part of this great team!

Share/Save

I just uploaded FEST-Swing 1.2.1 to CodeHaus’ Maven repository. This release is targeted to Maven users only. The reason? I made a big mistake when I released FEST-Swing 1.2: I uploaded the wrong version of the dependency FEST-Util, making the Maven version of FEST-Swing completely unusable.

Artifacts uploaded to CodeHaus’ Maven repository are automatically uploaded to Maven’s central repository. Once there, artifacts cannot be changed.

Besides fixing the FEST-Util dependency, there are no changes in source code.

The version uploaded to the Downloads page has the correct dependencies. It was not necessary to make any changes.

Share/Save

Once I got my new PC last weekend, the first thing I did was to install Ubuntu 10.4 in VirtualBox (now updated to 3.2.4) in a Windows 7 host. Installation of both VirtualBox and Ubuntu was quick and painless. They just work. Since I have a 30′ monitor and a powerful video card, I wanted to run Ubuntu to the maximum resolution possible (2560 x 1600.) Unfortunately, the default settings only allowed me to set the display resolution to an awful 1024 x 768.

After a couple of days, I found some instructions on how to increase the screen resolution of a Ubuntu virtual machine. I basically had to:

1. Install VirtualBox “Guest Additions”
2. Add the desired screen resolution to the xorg.conf file

Since I’m a Linux/VirtualBox newbie, I followed the instructions carefully. In theory, I just needed to right-click the icon and select “Open with Autorun Prompt” to install the Guest Additions. Once I did that, I tried to edit the xorg.conf file, but my copy of Ubuntu didn’t have one! I found instructions on how to create a new one, but it never worked. I was completely sure I wanted to use Ubuntu as my primary desktop and I was not going to give up!

Finally I found out that I was not installing the Guest Additions correctly and that I didn’t have to edit any xorg.conf file. This precious link, http://mylinuxramblings.wordpress.com/2010/05/23/running-kubuntu-10-04-in-virtualbox-as-a-guest-os/, pointed me in the right direction.

Now the screen resolution of my Ubuntu virtual machine changes dynamically when I resize the VirtualBox window. I can turn on all visual effects as well. Here is a screenshot of my Ubuntu virtual machine, at 2560 x 1600 (click to enlarge)

Share/Save

I’m proud to announce the release of FEST-Swing 1.2!

FEST-Swing is a Java library that provides a fluent interface for functional Swing GUI testing. This library provides an easy-to-use API that makes creation and maintenance of GUI tests easy.

Release notes

Bug

• [FEST-341] – Error in ScreenshotOnFailureListener.takeScreenshotAndReturnFileName. Thanks to Grego.
• [FEST-342] – Javadocs in methods annotated with @RunsInCurrentThread are wrong.
• [FEST-345] – KeyStrokeMappingProviderNames uses the wrong name for KeyStrokeMappingProvider. Thanks to Olivier DOREMIEUX.

Improvement

• [FEST-347] – Incorporate keyboard mapping for French MacOS. Thanks to Olivier DOREMIEUX.
• [FEST-348] – Fix implementation of ‘selectAll’ in JTextComponentDriver. Thanks to Olivier DOREMIEUX.
• [FEST-355] – ComponentFixture validateNotNull method visibility.

New Feature

• [FEST-354] – Move class SystemProperties from fest-swing to fest-util.

Task

• [FEST-343] – Update FEST-Reflect dependency to version 1.2.
• [FEST-344] – Update FEST-Util dependency to version 1.1.2.

For a complete list of changes made in version 1.2, please read our previous releases: 1.2rc, 1.2a4, 1.2a3, 1.2a2 and 1.2a1.

FEST-Swing can be downloaded here (file fest-swing-1.2.zip.) FEST requires Java SE 5.0 or later.

Links

• Home page
• Wiki
• Change report
• Javadocs
• Getting Started
• Issues
• Users’ Group

Feedback is always appreciated :)

Share/Save

I’m proud to announce the release of FEST’s JavaFX Compiler Maven plug-in 1.0b1!

This plug-in compiles JavaFX source and test files.

Features

• Compiles JavaFX source and test files
• Does not require JavaFX distribution to be in a Maven repository (according to its license, only Oracle can distribute JavaFX)
• Does not require to list all JavaFX libraries as dependencies in your pom.xml

Example

<build>
  <plugins>
    <plugin>
      <groupId>org.easytesting</groupId>
      <artifactId>javafxc-maven-plugin</artifactId>
      <version>1.0b1</version>
      <executions>
        <execution>
          <id>compile</id>
          <phase>compile</phase>
          <goals>
            <goal>compile</goal>
          </goals>
        </execution>
        <execution>
          <id>test-compile</id>
          <phase>test-compile</phase>
          <goals>
            <goal>testCompile</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

The listing above will:

1. call the “compile” goal in the standard Maven “compile” phase.
2. call the “testCompile” goal in the standard Maven “test-compile” phase.

As a result, if we execute “mvn test” both JavaFX sources and test sources will compiled automatically.

Release Notes

New Feature

• [FEST-314] – Create test-compile goal for JavaFX Maven plugin.

Improvements

• Change JDK version to 1.6.
• Renamed artifactId to javafxc-maven-plugin.

The FEST JavaFX Maven plugin can be obtained from our Maven Repository.

Links

• Documentation
• Change report
• Issues
• Users’ Group

Feedback is always appreciated :)

Share/Save