Java and Technology weblog
This post shows how to run all the tests in IntelliJ for a multi module maven project.
Thanks to everyone who came to my “Unit Testing – the Hard Parts” presentation @ New York Code Camp. I really enjoyed it! Great crowd, lots of follow up questions. And cool Microsoft office space in Times Square. Thank you to all who attended. My slides are here: http://www.slideshare.net/shaunabram/unit-testing-the-hard-parts
Most classes have collaborators. When unit testing, you usually want to avoid using real implementations of those collaborators to avoid test brittleness and binding/coupling, and instead use Test Doubles: Mocks, Stubs and Doubles.
I’ve found the builder design pattern occasionally useful in code, but frequently useful in tests. This article is a quick summary of the pattern in general, followed by look at a working example of using it in tests. See the code in github.
Software quality is critical to consistently and continually delivering new features to our users. This articles covers the importance of software quality and how to deliver it via unit testing, Test Driven Development and clean code in general.
Oh dear, yet another ‘Hello World!’. But although the functionality is trivial, this little SpringMVC project is complete enough for me to use as a template to bootstrap more complex projects. It consists of:
- HTML/JSP client
- SpringMVC server using a Controller/Service/DAO design
- Maven for build and dependency management
This is an updated version of an older project I created, with the following enhancements:
- Added a full suite of automated tests (unit, integration and browser based)
- Incorporated into a continuous deployment environment
As a follow up to the Hamcrest post I made yesterday, I wanted to post an example of my own Hamcrest matcher implementation. This matcher tests if a string contains a specified number of substrings.
An example usage could be:
String sql = "select a,b,c from tableA"; assertThat(sql, hasNumberOfSubstrings(",", 2));
I have also attached a jar which includes the associated unit tests, although you will need the hamcrest-unit-test project to compile, which can be downloaded as part of the hamcrest all-in-one jar.
Hamcrest is a framework for writing matcher objects. Matchers have a variety of uses, but are particularly useful when writing unit tests. Instead of using JUnit’s assertEquals methods, we use Hamcrest’s assertThat construct with one (or more) of the many Matchers available. For example
A small change in this example, but Hamcrest’s benefits are many, enabling you to write much more flexible tests that are easier to read and have more meaningful failure messages.
I attended another great San Francisco JUG meeting tonight, this time on How to use Selenium with Maven/Ant to automate testing of web apps.
The talk was given by Chris Bedford, from Build Lackey Labs – “Automating the Monkey Work Out and the Quality In!”. Overall, I thought this was a great talk by Chris. He clearly has a huge amount of experience creating automated tests and integrating them with build tools and he gave a well structured, interesting, well delivered presentation. I have posted a copy of Chris’s slides and I think the video will be posted on the SF JUG site at some point, but I have also posted my notes from the presentation below…
I recently converted a project I have been working on to use Maven. After setting up all the dependencies in the pom, I got everything compiling fine but ran into problems getting the unit tests to pick up the hibernate config (hibernate.cfg.xml) and hibernate mapping (*.hbm.xml) files. With hindsight, it is straightforward, but it took me a while to figure it out so I thought I’d post the solution here.
Initially, I had my hibernate.cfg.xml file in the following directory
And when I first tried to run my hibernate unit tests (mvn test), I got this error:
SessionFactory creation failed.org.hibernate.HibernateException: /hibernate.cfg.xml not found
Some checking of the maven docs and some forums revealed the following possible solutions:
1) Copy the hibernate.cfg.xml file to
This works, however I think it is a hack as the target folder is generated rather than being somewhere you should actually manually create files.
2) The next solution I found suggested moving the hibernate.cfg.xml to
This works well as the contents of this folder are copied to the base level of the my-app/target/classes folder so it is basically a ‘more correct’ solution than the first.
3) The next and I think best solution was to create a new, duplicate hibernate.cfg.xml inside
This allows a different hibernate.cfg.xml file to be used for testing and, for example, facilitates connecting to a different database (such as hsqldb) for testing while continuing to use your regular database (such as MySQL) for the app itself.
A couple of points to note:
1) The hibernate mapping files (i.e. the *.hbm.xml files) should also be in the resources folder (in whatever directory structure you choose) to ensure that these too are accessible by the unit tests.
2) I am not (yet) using Spring with the hibernate components, which would likely have changed the above setup.