JPz'log Coin Coin and Plop da Plop

29Sep/094

ScalaTest in Maven

ScalaTest is a wonderful testing framework written in Scala that embraces several styles of testing (JUnit-style, behavior-driven, etc). Of course we live in a polyglot programming world, hence you don't have to code in Scala to leverage its power :-)

I recently coded in Scala and found that running ScalaTest from Maven is all but a straightforward thing to do.

First of all, I suggest that you jump on the 1.0-SNAPSHOT versions as they contain a JUnit bridge (and other refinements).

Add this to your pom.xml:

(...)
        <dependency>
            <groupId>org.scalatest</groupId>
            <artifactId>scalatest</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>test</scope>
        </dependency>
(...)
        <repository>
            <id>scala-tools.org releases</id>
            <name>Scala-tools Maven2 Releases Snapshots Repository</name>
            <url>http://scala-tools.org/repo-snapshots</url>
        </repository>
(...)
    <pluginRepositories>
        <pluginRepository>
            <id>scala-tools.org</id>
            <name>Scala-tools Maven2 Repository</name>
            <url>http://scala-tools.org/repo-releases</url>
        </pluginRepository>
    </pluginRepositories>
(...)

You then need to make sure that your Scala code is properly compiled from the tests classes location:

(...)
    <build>
        <sourceDirectory>src/main/scala</sourceDirectory>
        <testSourceDirectory>src/test/scala</testSourceDirectory>
        <plugins>
            <plugin>
                <groupId>org.scala-tools</groupId>
                <artifactId>maven-scala-plugin</artifactId>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                            <goal>testCompile</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
(...)

In my case, I am writing tests as specifications that I want to be run from JUnit:

import org.scalatest.junit.JUnitRunner
import org.junit.runner.RunWith
import org.scalatest.Spec
import org.scalatest.matchers.ShouldMatchers
 
@RunWith(classOf[JUnitRunner])
class AutomatonSpec extends Spec with ShouldMatchers {
    (...)
}

Finally, make sure that the Maven Surefire plugin will pick up the specification classes and pass them to JUnit:

(...)
    <reporting>
        <plugins>
(...)
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <configuration>
                    <includes>
                        <include>**/*Spec.class</include>
                    </includes>
                </configuration>
            </plugin>
        </plugins>
    </reporting>
(...)
Filed under: English, Geeking, Howto, Technologies 4 Comments
25Sep/090

Soundcloud

I have recently discovered Soundcloud, a very fine platform for hosting audio productions.

Among the things that I liked is the very nice Flash player that they have:

Mix-2009-09-23 by hclcast

Filed under: Fun No Comments
16Sep/095

Start in Git, push to Subversion then work with git-svn

Git is frequently used as a Subversion client through git-svn. The nice thing about git-svn is that you can use the Git goodness (distributed workflow, offline support, sensible branching/merging, etc) on a project that is hosted in a Subversion repository. It just takes a while the first time as it needs to convert the Subversion repository history

However, less information can be found when you put things the other way around, i.e., when you start doing your work in Git then need to push it to a Subversion repository.

An easy workaround is of course to forget the history that you recorded in Git and simply push your content to Subversion. It is however more comfortable to push those changes to Subversion (step 1) and keep working in Git, occasionally pushing back to Subversion as you would normally do with git-svn (steps 2 and 3):

svnpush

Here's how I did on recent project.

First of all you need your target Subversion URL to exist. If need be, create the repository and its structure. In my case I was going to push to a sandbox part of an existing Subversion repository, hence I first created the target directory (server, repository and project informations have been intentionally replaced):


svn mkdir https://server/svn/repo/sandbox/my-project

Next thing was to tell Git that it should track some Subversion history. It boils down to editing .git/configs from your Git repository and adding the following subsection:


[svn-remote "svn"]
url = https://server/svn/repo
fetch = sandbox/my-project:refs/remotes/svn

This creates a new remote branch called remotes/svn. You can rename it of course, and even add some branches and tags entries (see the git-svn documentation).

You can now import the (empty!) Subversion history into the remotes/svn branch:


git-svn fetch

This is not over yet. Indeed, remotes/svn and your current branch (master in my case) do not share any history: the one from Subversion is empty while your Git branch has one. What's more, your master branch is not linked with the Subversion metadata that allows git-svn dcommit to work. The solution is to rebase first:


git rebase remotes/svn
git svn dcommit

This can take some time depending on your Git history, as the rebase operation replays your commits on the empty Subversion history, while the dcommit pushes each commit to Subversion.

It's as simple as that, all you need is mainly some Git configuration editing.

Filed under: English, Geeking, Howto 5 Comments
   

Info

View Julien Ponge's profile on LinkedIn
Fork me on GitHub

Twitter Updates

Archives

JPz'log is Digg proof thanks to caching by WP Super Cache