JUnit test class names are important with maven

maven-logo-black-on-white

junit-logo

I came across a funny issue on utils (available here) today, basically 2 unit tests were not executed by Apache Maven on Travis CI.

It’s funny beacause it happened to me before, so I knew how to fix this problem.

On my machine I usually run JUnit tests with the JUnit plugin integrated into the Eclipse IDE because it’s nice, green/red, failure log, stacktrace and stuff.

Instead, when calling from the command line mvn test, Maven uses the maven-surefire-plugin to execute the tests. In its documentation it says that the default configuration, which I can’t be bothered to change, is to pick up every file name that matches this expressions:

  • **/Test*.java
  • **/*Test.java
  • **/*TestCase.java

A typo like NullCheckerTests, instead of NullCheckerTest prevents the tests in the class from being executed because the class it’s just ignored during test execution.

The solution it’s easy, following naming conventions, I think it’s nice to call all my test with an ending *Test in the name of the file and class, after all if you’re declaring an xxx test class, so it should be called XxxTest in a file named XxxTest.java.

An example of the problem and the relative solution can be found here.

I thought that sharing this issue could be useful if anybody encountered the same problem.

By the way, because of this issue I released version 1.0.5 of utils.

Utils

Long time, no see.. It’s been a very busy year to say the least.

I always liked to solve problems, to write code and experiment with stuff, so as you do, I developed some personal projects to try out new things.

I usually develop in Java, using Apache Maven as my build and dependency management tool, in my spare time and at my job too. I’ve noticed that I usually keep my general purpose utilities classes under packages like *.utils or *.helper.

This led to a lot of copy-pasted code all over the place. A lot of methods were also untested. I couldn’t even be bothered to look inside the other projects if there was already what I needed, so I ended up re-writing already existent stuff, that’s for sure.

I finally decided that I’m done with this mess.

I started a project called utils, and I choose that it should be open source and available under the BSD 3-Clause License.

The source code is hosted on GitHub and I put the project under continuous integration testing with a service called Travis CI. I use another service called Codacy that provides automated code analysis. I also discovered another service called JitPack looking around for a quick way to share my artifacts online. The home page of JitPack reads “Easy to use package repository for Git” and I can say that’s really great! It uses maven as the build tool, provides artifacts for sources/javadoc and it’s integrated with GitHub release system (just tag your code on git and you’re good to go basically, artifacts are online usually the order of seconds).

All this services are free for open source and it’s a great technological stack to write good code, check them out.

Here’s what i’ve setup for the project:

utils is open source and in development so, of course suggestions, critics, contributions and whatever are welcome.

Soundcloud API test.

I’m planning to develop a web application to search for free music and stream it online from various sites.

The first one I thought about was soundcloud that gives you access to their APIs here.

So I just pulled up this little python script to test it out.

It uses the soundcloud-python package wich is downloadable with pip or easy_install.

pip install soundcloud

easy_install soundcloud

just edit the client_id='YOUR_CLIENT_ID' line with the actual client ID. And try it out with a random track, pretty easy. Check the terms of use, of course.

More to go :)

Cool tutorial for stellaris launchpad on linux

You can find right here a good tutorial on how to setup a working environment for the stellaris launchpad board on GNU/linux (debian).

The cool thing this uses eclipse and open ocd to debug a project right in eclipse! I can’t wait to try this out!

Be sure to have a look at it!

Debugging a program on the stellaris launchpad board

OpenOCD now supports TI’s stellaris launchpad. Patching it it’s no longer necessary!
The source it’s available here!

After creating a template for the Stellaris Launchpad, I wanted to debug it and my own programs as well.

So I installed openOCD and used gdb (for arm-none-eabi) to debug it and see if it works properly.

I writing here a tutorial to help someone who would like to do the same.

The first thing to do it’s obtaining a compile toolchain, I’m lazy and I use the arm-none-eabi from Codesourcey that’s already built from them and free to use as I described it here.

When you got that working the next step it’s getting the Stellarisware software, the process it’s described here too. (It’s not really needed, but if you want to do something quickly that’s the way to go because the API for it it’s well documented and easy to use).

After doing the previous steps you need to get the source code of openOCD, patch it and build it. You can find how all this born in (this forum topic).

You’ll need git, which you can get on Ubuntu just opening a terminal and typing:

sudo apt-get install git-core

You need to get the latest openOCD source code so type on the terminal:

cd ~/stellaris/
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd

This will create a directory called openOCD containing all the source files of the project. then you need to install the libraries you’ll need to built it. So again type in the terminal:

sudo apt-get install libtool autoconf texinfo libusb-dev

This tutorial will just focus on the Launchpad board, you’d probably need other libraries if you need to build openOCD for other dongles.

The next step it’s to patch the sources with the latest patch from this archive (thanks Spencer Oliver). The process it’s quite easy and you can choose different methods to do it, I’ll go for the git pull to the project so type:

git pull http://openocd.zylin.com/openocd refs/changes/22/922/10

And git will automatically patch the sources with the latest patch revision.

Then you’ll need to build openOCD, there are plenty of information on the README file, basically I just did this:

cd openocd
./bootstrap
./configure --enable-maintainer-mode  --enable-ti-icdi
make

I skipped the “make install” step.

I then created a directory with the binary file and all the other configurations needed:

cd ~/stellaris
mkdir openocd-bin
cp -r ./openocd/tcl/* ./openocd-bin
cp ./openocd/src/openocd ./openocd-bin

Then you’ll need a .cfg file to pass the openOCD, I used the one this guy made, because I’m lazy (haven’t I told you?). So just make a file called LM4F120XL.cfg in the openocd-bin folder and copy the following in it:

# TI Stellaris Launchpad ek-lm4f120xl Evaluation Kits
#
# http://www.ti.com/tool/ek-lm4f120xl
#
#
# NOTE: using the bundled ICDI interface is optional!
# This interface is not ftdi based as previous board were
#
source [find interface/ti-icdi.cfg]
set WORKAREASIZE 0x4000
set CHIPNAME lm4f120h5qr
source [find target/stellaris_icdi.cfg]

Now a quick check, the openocd-bin folder should contain the following files:

bitsbytes.tcl
board
chip
cpld
cpu
interface
LM4F120XL.cfg
memory.tcl
mem_helper.tcl
mmr_helpers.tcl
openocd
target
test

Now you’re ready to launch it from here with sudo, connect the board to a USB port and just type in the command line:

sudo ./openocd --file ./LM4F120XL.cfg

Now that you’ve got it running open another terminal to download a template project I made, to run it on the board and debug it! So type:

cd  ~/stellaris
mkdir projects
cd projects
git clone https://github.com/scompo/stellaris-launchpad-template-gcc.git

This will clone the project into the stellaris-launchpad-template-gcc folder. You just need to open up the Makefile with any editor and change this:

# Stellarisware path
STELLARISWARE_PATH=~/stellaris/stellaris/

With the path to your stellarisware main folder. Then you can just build your project typing:

make

Then comes the cool part of the process, see if the program it’s running properly, so just connect arm-none-eabi-gdb to open ocd, load the program and see if everything it’s good!

arm-none-eabi-gdb main.axf

This will open up gdb for arm-none-eabi with a target file called main.axf. Next will type to the (gdb) prompt, so let’s do something useful (Again thanks a lot the the stellaristi forum guys for this)!

target extended-remote :3333
monitor reset halt
load
monitor reset init

Now the target processor it’s halted at the beginning of the startup_handler() code of the LM4F_startup.c file. Supposedly this will work fine doing it’s magic, but check it out, and if you find any strange behavior just tell me opening an issue in the github project page. So let’s go on and just set some breakpoints and display some the variables at each break.

b main.c:51
b Timer1A_ISR
display count
c

The c command will just continue the execution of the program from the breakpoint. If you need any help just type help in the gdb prompt window.

Everytime you’ll write c to continue executing the program you’ll see that the variable count will be updated, so basically the interrupt routine it’s running and updating the volatile variable. Well, we’re good then!

To exit gdb just enter “q” and confirm with “y”.

To exit from openocd just use “ctrl”+c like every command line program in linux. I’ve noticed that I need to disconnect and riconnect the board sometimes to restart openOCD so if it’s the case, just go for it doing this.

This would hopefully be a starting point for your own projects, just copy this template folder and start doing everything you want! Good hacking!