blog.codeleak.pl

Parameterized unit tests are used to to test the same code under different conditions. Thanks to parameterized unit tests we can set up a test method that retrieves data from some data source. This data source can be a collection of test data objects, external file or maybe even a database. The general idea is to make it easy to test different conditions with the same unit test method, which will limit the source code we need to write and makes the test code more robust. We can call these tests data-driven unit tests. The best way to achieve data-driven unit tests in JUnit is to use a JUnit's custom runner - Parameterized or JUnitParams' JUnitParamsRunner . Using JUnit's approach may work in many cases, but the latter seems to be more easy to use and more powerfull.

Collective code ownership is very important part of any successful Agile project where everyone in the team shares responsibility for the quality of code. Any developer can change the code, fix the bug he notices and refactor as the code belongs to the team.

Yet another tutorial about creating Web API with Spring MVC. Not really sophisticated. Just a walkthrough. The resulting app will serve simple API, will use Mongo as its persistence and it will be secured with Spring Security.

Among many new features in Spring 4 I found @ControllerAdvice improvements. @ControllerAdvice is a specialization of a @Component that is used to define @ExceptionHandler, @InitBinder, and @ModelAttribute methods that apply to all @RequestMapping methods. Prior to Spring 4, @ControllerAdvice assisted all controllers in the same Dispatcher Servlet. With Spring 4 it has changed. As of Spring 4 @ControllerAdvice may be configured to support defined subset of controllers, whereas the default behavior can be still utilized.

Today I migrated one of my projects, that I am currently working on, to Spring 4.0. Since it is a really simple web application I use to learn and demo Spring features, I only needed to update the POM file of my project and change the Spring version. I deployed the project to Tomcat 7 server and apparently the application did not start. I saw this message in IntelliJ console: Failed to load bean class: pl.codeleak.t.config.RootConfig; nested exception is org.springframework.core.NestedIOException: Unable to collect imports; nested exception is java.lang.ClassNotFoundException: java.lang.annotation.Repeatable . What the ...?

After some years with JSP/JSTL and Apache Tiles I started discovering Thymeleaf for my Spring MVC applications. Thymeleaf is a really great view engine and it simplifies and speeds up the development despite that lack of good IntelliJ (vote here: http://youtrack.jetbrains.com/issue/IDEABKL-6713 ) support at the moment (there is an Eclipse plugin though). While learning how to use Thymeleaf I investigated different possibilities of working with layouts. Apart from the native fragment inclusion mechanism there are at least two options to work with layouts: Thymeleaf integration with Apache Tile and Thymeleaf Layout Dialect . Both seem to work fine, but inspired by this comment about a simple and custom option, I gave it a try. In this post I will show I created the solution.

Thymeleaf 2.1 release arrived. The new version brings plenty of new features in its core as well as in Spring Integration module like improvements of fragments inclusions, rendering view fragments directly from @Controller, improved form validation error reporting to name a few. But is it worth upgrading to Thymeleaf 2.1? Let's see.

To build a good team you need to look for really good people. In my current company , we are instantly looking for good developers ( http://kariera.goyello.com/ ). I am personally engaged with recruitment for Java developers (not only though). It is not easy job to find good people. During all the years, we have been adjusting our process and we ended up with really simple assignment that we give during the technical part of the interview. And sometimes it is amazing what we see there!

As a Team Leader I work with a range of different tasks everyday. They are related to many aspects of my current company life from managing multiple teams, multiple projects, customers, improvements, reports to name a few. I work with short term tasks but also with long term ones like e.g. improvements. This makes that I have more tasks I am able to manage. It requires from me a good organization of work to get things done.

In Spring MVC the @RequestBody annotation indicates a method parameter should be bound to a body of the request. @RequestBody parameter can treated as any other parameter in a @RequestMapping method and therefore it can also be validated by a standard validation mechanism. In this post I will show 3 ways of validating the @RequestBody parameter in your Spring MVC application.

Read how to customize code templates for JUnit 4 test, setup and teardown methods in IntelliJ.

In JUnit there are many ways of handling exceptions in your test code: try-catch idiom With JUnit rule With @Test annotation With catch-exception library With custom annotation With Lambda expression (as of Java 1.8) With AssertJ 3.0.0 for Java 8 (NEW!) With JUnit 5 built-in assertThrows Which one should we use and when?

To improve the readability of my unit tests I use assertThat with Hamcrest matchers. This is a good way to improve readability of your test code, especially when I statically import members of like org.junit.Assert.assertThat and org.hamcrest.Matchers . But when I add Mockito matchers on top of it, I experienced the problem of static import conflicts that ended up with "not nice" code (according to my definition).

I have been working with unit testing for several years and I always had problems in finding the best names for my tests. I have been trying different conventions and I ended up with the practice of naming tests based on the behavior they test.

@PathVariable annotation is one of the Spring MVC features that allows creating RESTful Web application much easier. It indicates that a handler method parameter should be bound to a URI template. In this post I will present two useful tips for working with this annotation.

Default Tomcat error pages look scary. In addition, they may expose valuable information including server version and exception stack trace. Servlet specification provides a way to configure an exceptional behavior through web.xml. One can configure either reaction on a specific Java exception or to a selected Http response code(s).