testdriven.com Wrangling quality out of chaos

Archive for December, 2005

Parabuild 2.0, Released, Helps Reduce Risks Of Failures Of Software Projects

12.06.2005 · Posted in Tools

Mountain View, California – November 21, 2005 – Viewtier Systems, Inc., today announced the release of its software build management server Parabuild 2.0. Parabuild helps software organizations reduce high risks of failures of projects caused by broken code base by delivering uninterrupted daily builds[.

Software build is a process of transforming of project source code into a working application. Broken builds cause delays and overspending that may increase risks of project failure. Parabuild cures acute pain of broken code bases. With Parabuild, daily builds can succeed if the head of the code base is broken. Continuous integration builds provided by Parabuild ensure that new changes integrate into existing code base.Key Parabuild Features

Continuous integration builds.
Daily, nightly and QA builds.
Integration with JUnit.
– High speed Web interface.
– Integration with ClearCase, Perforce, Visual SourceSafe,Surround SCM, CVS and Subversion.
– Build scripting: shell scripts, Perl, make, MSBuild, nmake, ANT, nANT, Maven, Jam and VB.
– Multiple platform support: Windows, Cygwin, Linux, Solaris, HP UX and generic Unix, including Mac OS X.
– Release notes from Bugzilla, Perforce jobs and Jira.
– Two-minutes installation; fifteen minutes to first build.

Why Parabuild

Uninterrupted daily builds.
Remote multiplatform builds.
Running existing build scripts.
– Low to zero administration.
– Searchable logs and results archive.
– Group-based security.

A working evaluation version of Parabuild 2.0 is available for download at http://www.viewtier.com/downloads/index.htm.

rMock 2.0.0 release candidate 1 has been released

12.06.2005 · Posted in Tools

After five weekly beta-releases we feel that rMock-2.0.0 is mature enough for a first release candidate.

When You download and start using rMock You will find several features that you recognize both from EasyMock and jMock. You record expectations like with easyMock, but modifications look more like JMock.

rMock differs from both JMock and EasyMock primarily by its stricter workflow. All mocks change state at once, always. All mocks are verified automatically, at the same time, without exceptions.While testing You need both interaction-based and state-based tests. rMock provides consistent tools for both, Your custom constraints can be used state-based with the assertThat method or interaction-based by modifying your expectations.

rMock always provides all the information available on failure, both state-based and interaction-based. Are you currently verifying or recording? Are there any unmatched expectations? Which expectations can match?

That is not all; rMock also provides an innovative feature called dynamic suites. Dynamic suites help you manage your tests consistently both in build time and development time, making sure that no tests are left out of the suite unintentionally. Again, the same familiar constraint model is used, this time to select tests for your suite.

Here are a few of the more interesting features of rMock:

* rMock is tested with rMock in java 1.3 and java 1.5

* Strict flow of your tests, in the name of clarity
— rMock has a strict record, modify and verify flow.
— All mocks automatically verify themselves in the post verification phase.

* Full support for mocking of classes
— Actions can be forwarded to the underlying implementation if desired.

* Interception of invocations to collaborating objects
— Expect certain calls: Has close() been called on your ByteArrayOutputStream?
— Forbid certain calls: The class under test is not supposed to call close()
— Fake exceptions and much more

* Consistent constraint model in both state-based and interaction-based testing.
— The assertThat(<actual>, <expression>) can be used in place of the traditional assertXxxx(<expected>, <actual>) methods.
— If an assertThat fails rMock tells you if you are still setting up or verifying.
— If an assertThat fails rMock reports which expectations are not yet fulfilled.

* Define structure with sections
— beginSection(<section>) and endSection() groups your expectations so that your intentions with the test become clearer.
— Enforce order with an ordered section
— Unordered and ordered sections can be nested to any level giving you the tools to express yourself.

* Convenient mock declaration
— if your method returns an interface, a mock is automatically created for you when it is invoked in the recording state.
— Classes that have a no argument constructor can be mocked the same way as interfaces.
— If your class needs constructor arguments, the constructor can be selected by explicitly specifying its parameter types, or you can let rMock figure out which constructor to use based on the parameters you pass.

rMock is the first step in our concept of Test Driven Documentation. We beleive that most of the relevant documenation in a project could, and should be generated from tests in order to keep it consistent, up to date and sufficiently detailed.

Being able to generate documentation from tests would further increase their value, leaving more time for refactoring and gaining even more benefit from writing clear, understandable code.

In our sister project rDoc we have already generated first sequence diagrams from tests. And following the "eat your own dog food" fashion, in which rMock has been developed, we are working hard to be able to generate all rMock documentation and examples from our tests.

Sounds interesting? Check out rMock for a start and stay tuned for the first release of rDoc.

Joakim Ohlrogge on behalf of The rMock team