DDevelopment & Design

Agile Skills Project at my company

Unfulfilled programmers Erich Fromm, a famous humanist, philosopher and psychologist strongly believed that people are basically good. If he was right, then either our society is a mind-breaking dystopia or we have a great misfortune of working i… Unfulfilled programmers Erich Fromm, a famous humanist, philosopher and psychologist strongly believed that people are basically good. If he was right, then either our society is a mind-breaking dystopia or we have a great misfortune of working i…

Unfulfilled programmers Erich Fromm, a famous humanist, philosopher and psychologist strongly believed that people are basically good. If he was right, then either our society is a mind-breaking dystopia or we have a great misfortune of working in a field that burns people out, because many IT people I know are more like Al Bundy than anyone else. Why is being a couch potato something wrong? Happiness can be achieved in many different ways, but not by passive pleasures. One way of pursuing happiness is by self realization and while self realization can happen in any activity, it’s makes perfect sense to have it at work, where you spend one third of your life time anyway. But many developers I know, consider work as something boring at best, dreadful at worst. True, programming can be awful, when you have to dig deep into a terrible code base without any perspective for a change, but IT is vast and you can always find something interesting, and once you learn it, you will find a way to make money on it, either by changing position inside your company or changing your employer altogether. Yet most unhappy IT professionals don’t do anything to change their situation. The main reason for that is, because it requires a lot of learning, and learning at home is not the most beloved activity for a couch potato. So why are developers turning into couch potatoes in the first place? Why the last thing a typical developer will do back home is learning and polishing his skills? There are plenty of reasons for that. The three main roots of an IT couch potato First, our work is tiresome. Nearly every job offer you can find mentions “able to work under pressure” and “flexible long working hours” in the requirements. This translates directly to the “burn-out” phenomenon. Second, the technological landscape is changing overwhelming fast. Unless you work for a slowly adapting institution like a bank, your skills will be outdated in a few years time. Sure the deceased Sun, god help us, granted Java developers four years of relative stagnation, but that’s an exception and it’s going to end soon enough anyway (unless, of course, these are just convulsions before slow death of technology). You better learn and you better learn fast, or you’ll have no other option than to promote yourself into management. Third, just how long can you sit by your computer everyday? Yeah, I know, some people spend years playing WoW, Eve and alike, barely moving. I am a sinner myself, with Steam reporting over 350 hours in Modern Warfare 2, 200 hours in F.E.A.R. 2 multi, and countless months of my life wasted by Sid’s Civilization. But for not-addicted, it’s just simply stupid, not to mention unhealthy, to have your ass integrated with the chair. No matter how comfortable it may be. There is more to life than that. Case Study at my company It all started with a few SQL programmers grumbling about how they are bored to death, and how they would like to switch to OO programming. I’m not a person who waits, so next thing I did was asking our management if they could move those guys to Java/C# projects. And the management was all for it, with just one requirement: they would have to first learn our technology stack at home, not to be totally lost and unproductive. After all, the more technologies an employee know, the more valuable he is for the employer (think about switching people between projects). A few months later and nothing has changed. I’m asking sql guys how the learning is going, and I get the answer: it hasn’t started yet. Now, I know the best way to learn something is by hands-on experience at work. After all that’s why I’ve been changing my job a few times: to have a real world experience. It’s easier to learn french if you move to Paris. And learning at home is hard because of the aforementioned reasons. The very same reasons, why you get only 650 people on a free conference, like Javarsovia. So what can we do, then? How about we remove all the obstacles? How about we make learning at home fun, satisfying and profitable. How about we provide  motivation and feedback. How about we also solve the never-ending dissonance between employee’s financial and employer’s productivity expectations on the way. Sounds interesting? Let’s try, then. First: make it profitable. Up to some point, people get motivated by money. It won’t work if you are already earning enough to pay for everything you need, but in a country like Poland, to be able to build/buy yourself a house, you have to be making many times the average salary. So here, money is still a major motivator. Every year, every developer goes back to his boss and says: I want more. Guess what, your boss wants to pay you more. No kidding. After all Henry Ford’s said:

“There is one rule for industrialists and that is: make the best quality of goods possible at the lowest cost possible, paying the highest wages possible”. Highest wages. You boss really wants to pay more. But to stay in business, the company needs you to either improve the quality or productivity. Both mean more money to the business, and more money to pay you with. If you consider that, the goal of a developer who wants to learn something new (or get better at something) is on the way to make the company more profitable. After all, this is software development – you never know what technology you gonna need tomorrow. This works both for completely new stuff, and for learning something that company is already quite good at. If you know several technologies that the company is working with, you are more valuable, because you can handle more projects (you boss may think in terms of reallocating resources). After thinking about all of this I went to my bosses and asked them: will you pay more to the people who learn different technologies at home? Even when they can’t use them right now at work? Will you give a rise to those Oracle guys, if they learn Java? The answer was: definitely! They actually said that every time a developer asks for a rise, they ask him back: what have you done in the last year to improve your market value? What have you learned? Because every time an employee’s market value increases, the company’s value increases. Simply speaking: more skills means more money. Both for the developer and for the company. It’s amazing, how often people forget about it. Making it crystal clear can give you a motivational boost to do something at home and a nice perspective. You don’t have to switch your job to get a rise. You need to learn more, and they’ll happily pay you more. Second: make it easy The main question with learning is where to start from? And for software developers it’s the most important, most difficult question, because there is no way to learn everything, because spending years studying can be simply a waste of time, if the technology is dead/outdated the moment you get productive with it. What should I learn or why should I learn at all, if the risk of wasting the most precious thing in my life, my time, is so high? How do I decide what to learn. Lets make learning safe and easy. Your best bet is to start with something that has much longer life expectancy, something that will help you right away, no matter what a technology you have to work with in your next project. And something that is relatively simple to learn: agile skills. These are skills of an agile developer, well established, well recognized, and not going away any time soon, because we still do not have anything on the horizon that could surpass them. Yeah, I know, the world ‘agile’ is so popular nowadays, that even my grandma is agile, but lets go for a solid list of things agile. No bullshit theory, no marketing mumbo jumbo, give me a precise, distilled and refined list of things I should learn, things that will help me, things worth spending my time on. Here it is: The Agile Skills Project The project is all about self improvement and learning. It’s a great inventory of “ isolated, learned, practiced, and refined” agile skills, with definitions, resources, descriptions of steps to mastery and success stories. Take a look at the “Pair Programming” page, for example. All the skills are divided into different areas: Business Value, Collaboration, Confidence, Product, Self Improvement, Supportive Culture, Technical Excellence. You even get a nice mind-map with it. This is a single reference point for all those who do not know where to start or where to go next. All these skills are in high demand on the market and with a very long Time-To-Live. The best thing is though: no matter what technology you gonna work with tomorrow, you can benefit from them. I took the list from the website, tidied it up a bit, refactored it for the needs of my company, and proposed it as a Request For Comment, a wiki page, where everyone gets to discuss and shape up the idea, before we give it to the management. Soon we had a discussion. It wasn’t easy to make everyone understand the concept, but after a while people joined in, and we added some more stuff. Level up! The Agile Skills Project is more than a simple index. It tries to create a learning ecosystem, by defining quests:
“Quests” are on-the-job experiments, self-assessments, peer-reviews, course experiences or other activities intended to help a person better apply a particular agile developer skill set. It’s a bit like a Role Playing Game. You have your quests, you do them, you get experience. For experience you get more money and new toys (technologies) to play with.  It’s fun. Billions of MMORPG players cannot be wrong. But to make that happen we need something every game has: feedback. Third: give feedback OK, so we have a bit of motivation (money) and a list of goals (agile skills). Who is going to give us quests, and who is going to tell us we did a good job? How will we have our feedback? The first and most important thing, is to see the results of you actions. Otherwise you loose focus and motivation (money can only get you that far). Therefore you should create a list of quests you have done. Put it on the intranet or somewhere, where you can show it to others. It’s important, because you are going to share it with your mentor. Yes, a mentor. Choose someone from your company, someone you trust, someone you respect. It doesn’t have to be an Einstein. Meet with this person once a month, during your work-time. An hour should do. Discuss with your mentor what quests you want to accomplish this month. Could be anything, reading an IT book, learning new programming language or taking another step to master one of the agile skills from the list. Tell your mentor when you’ll be done. Meet together again next month, and either put the quest in your done-list, or mark it as ‘failed’. The role of the mentor is to listen to you, remove obstacles, help you choose a good path and give you feedback. You’ll be surprised by how much the meeting with your mentor motivates you. It works much better than money: you don’t want to fail in the eyes of the mentor, because this is the guy you respect, and you want him to respect you as well. And once you see your constant improvement by filling the list of quests done with your mentor, it gets addictive. Smells corporate? How is this any different to what you can sometimes see in a corporation, with a year long plan of tasks your boss is giving you to accomplish to get your bonus? Well, first of all, these will be your quests, chosen by you. Second, you will choose your mentor as well. Your boss usually doesn’t know a thing about what you are doing. Third, it’s all about your self-improvement, not meeting some company goals. You get better at something, the company gets better at something. After all a company is not much more than the people working at it.  Fourth, it’s a fast feedback cycle, you do not have to wait till the end of the year to get it. And finally, it may be a bit corporate, because I have never seen any small company doing anything like this. But even if it is, it still seems like worthwhile. Anything to get me out of the couch. Discuss It’s a bit too early to tell whether the idea will be successful. We have just started. Fo me it is already helpfull, because with a list of quests done I have have a feeling of progress. If you’d like to discuss this, and other ways to animate software developers to do something more, I’m leading a meeting at Agile Warsaw group about it, on the 20th of September, 19:00. Feel invited. By the way, here you have a trial of “other ways to animate” from our internal TouK Code Jam Party, we held a week ago. Doesn’t look mych corporate, does it?

Solution Architect @ TouK

— Previous article

<!--:en-->Subtle feature of CONNECT BY<!--:-->

Next article —

Windows 7 - problem with login to your web application

You May Also Like
DDevelopment & Design

Spock basics

Spock (homepage) is like its authors say 'testing and specification framework'. Spock combines very elegant and natural syntax with the powerful capabilities. And what is most important it is easy to use.

One note at the very beginning: I assume that you are already familiar with principles of Test Driven Development and you know how to use testing framework like for example JUnit.

So how can I start?


Writing spock specifications is very easy. We need basic configuration of Spock and Groovy dependencies (if you are using mavenized project with Eclipse look to my previous post: Spock, Java and Maven). Once we have everything set up and running smooth we can write our first specs (spec or specification is equivalent for test class in other frameworks like JUnit of TestNG).

What is great with Spock is fact that we can use it to test both Groovy projects and pure Java projects or even mixed projects.


Let's go!


Every spec class must inherit from spock.lang.Specification class. Only then test runner will recognize it as test class and start tests. We will write few specs for this simple class: User class and few tests not connected with this particular class.

We start with defining our class:
import spock.lang.*

class UserSpec extends Specification {

}
Now we can proceed to defining test fixtures and test methods.

All activites we want to perform before each test method, are to be put in def setup() {...} method and everything we want to be run after each test should be put in def cleanup() {...} method (they are equivalents for JUnit methods with @Before and @After annotations).

It can look like this:
class UserSpec extends Specification {
    User user
    Document document

    def setup() {
        user = new User()
        document = DocumentTestFactory.createDocumentWithTitle("doc1")
    }

    def cleanup() {

    }
}
Of course we can use field initialization for instantiating test objects:
class UserSpec extends Specification {
    User user = new User()
    Document document = DocumentTestFactory.createDocumentWithTitle("doc1")

    def setup() {

    }

    def cleanup() {

    }
}

What is more readable or preferred? It is just a matter of taste because according to Spock docs behaviour is the same in these two cases.

It is worth mentioning that JUnit @BeforeClass/@AfterClass are also present in Spock as def setupSpec() {...} and def cleanupSpec() {...}. They will be runned before first test and after last test method.


First tests


In Spock every method in specification class, expect setup/cleanup, is treated by runner as a test method (unless you annotate it with @Ignore).

Very interesting feature of Spock and Groovy is ability to name methods with full sentences just like regular strings:
class UserSpec extends Specification {
    // ...

    def "should assign coment to user"() {
        // ...
    }
}
With such naming convention we can write real specification and include details about specified behaviour in method name, what is very convenient when reading test reports and analyzing errors.

Test method (also called feature method) is logically divided into few blocks, each with its own purpose. Blocks are defined like labels in Java (but they are transformed with Groovy AST transform features) and some of them must be put in code in specific order.

Most basic and common schema for Spock test is:
class UserSpec extends Specification {
    // ...

    def "should assign coment to user"() {
        given:
            // do initialization of test objects
        when:
            // perform actions to be tested
        then:
            // collect and analyze results
    }
}

But there are more blocks like:
  • setup
  • expect
  • where
  • cleanup
In next section I am going to describe each block shortly with little examples.

given block

This block is used to setup test objects and their state. It has to be first block in test and cannot be repeated. Below is little example how can it be used:
class UserSpec extends Specification {
    // ...

    def "should add project to user and mark user as project's owner"() {
        given:
            User user = new User()
            Project project = ProjectTestFactory.createProjectWithName("simple project")
        // ...
    }
}

In this code given block contains initialization of test objects and nothing more. We create simple user without any specified attributes and project with given name. In case when some of these objects could be reused in more feature methods, it could be worth putting initialization in setup method.

when and then blocks

When block contains action we want to test (Spock documentation calls it 'stimulus'). This block always occurs in pair with then block, where we are verifying response for satisfying certain conditions. Assume we have this simple test case:
class UserSpec extends Specification {
    // ...

    def "should assign user to comment when adding comment to user"() {
        given:
            User user = new User()
            Comment comment = new Comment()
        when:
            user.addComment(comment)
        then:
            comment.getUserWhoCreatedComment().equals(user)
    }

    // ...
}

In when block there is a call of tested method and nothing more. After we are sure our action was performed, we can check for desired conditions in then block.

Then block is very well structured and its every line is treated by Spock as boolean statement. That means, Spock expects that we write instructions containing comparisons and expressions returning true or false, so we can create then block with such statements:
user.getName() == "John"
user.getAge() == 40
!user.isEnabled()
Each of lines will be treated as single assertion and will be evaluated by Spock.

Sometimes we expect that our method throws an exception under given circumstances. We can write test for it with use of thrown method:
class CommentSpec extends Specification {
    def "should throw exception when adding null document to comment"() {
        given:
            Comment comment = new Comment()
        when:
            comment.setCommentedDocument(null)
        then:
            thrown(RuntimeException)
    }
}

In this test we want to make sure that passing incorrect parameters is correctly handled by tested method and that method throws an exception in response. In case you want to be certain that method does not throw particular exception, simply use notThrown method.


expect block

Expect block is primarily used when we do not want to separate when and then blocks because it is unnatural. It is especially useful for simple test (and according to TDD rules all test should be simple and short) with only one condition to check, like in this example (it is simple but should show the idea):
def "should create user with given name"() {
    given:
        User user = UserTestFactory.createUser("john doe")
    expect:
        user.getName() == "john doe"
}



More blocks!


That were very simple tests with standard Spock test layout and canonical divide into given/when/then parts. But Spock offers more possibilities in writing tests and provides more blocks.


setup/cleanup blocks

These two blocks have the very same functionality as the def setup and def cleanup methods in specification. They allow to perform some actions before test and after test. But unlike these methods (which are shared between all tests) blocks work only in methods they are defined in. 


where - easy way to create readable parameterized tests

Very often when we create unit tests there is a need to "feed" them with sample data to test various cases and border values. With Spock this task is very easy and straighforward. To provide test data to feature method, we need to use where block. Let's take a look at little the piece of code:

def "should successfully validate emails with valid syntax"() {
    expect:
        emailValidator.validate(email) == true
    where:
        email }

In this example, Spock creates variable called email which is used when calling method being tested. Internally feature method is called once, but framework iterates over given values and calls expect/when block as many times as there are values (however, if we use @Unroll annotation Spock can create separate run for each of given values, more about it in one of next examples).

Now, lets assume that we want our feature method to test both successful and failure validations. To achieve that goal we can create few parameterized variables for both input parameter and expected result. Here is a little example:

def "should perform validation of email addresses"() {
    expect:
        emailValidator.validate(email) == result
    where:
        email         result }
Well, it looks nice, but Spock can do much better. It offers tabular format of defining parameters for test what is much more readable and natural. Lets take a look:
def "should perform validation of email addresses"() {
    expect:
        emailValidator.validate(email) == result
    where:
        email           | result
        "WTF"           | false
        "@domain"       | false
        "foo@bar.com"   | true
        "a@test"        | false
}
In this code, each column of our "table" is treated as a separate variable and rows are values for subsequent test iterations.

Another useful feature of Spock during parameterizing test is its ability to "unroll" each parameterized test. Feature method from previous example could be defined as (the body stays the same, so I do not repeat it):
@Unroll("should validate email #email")
def "should perform validation of email addresses"() {
    // ...
}
With that annotation, Spock generate few methods each with its own name and run them separately. We can use symbols from where blocks in @Unroll argument by preceding it with '#' sign what is a signal to Spock to use it in generated method name.


What next?


Well, that was just quick and short journey  through Spock and its capabilities. However, with that basic tutorial you are ready to write many unit tests. In one of my future posts I am going to describe more features of Spock focusing especially on its mocking abilities.
DDevelopment & Design

Integration testing custom validation constraints in Jersey 2

I recently joined a team trying to switch a monolithic legacy system into set of RESTful services in Java. They decided to use latest 2.x version of Jersey as a REST container which was not a first choice for me, since I’m not a big fan of JSR-* specs. But now I must admit that JAX-RS 2.x is doing things right: requires almost zero boilerplate code, support auto-discovery of features and prefers convention over configuration like other modern frameworks. Since the spec is still young, it’s hard to find good tutorials and kick-off projects with some working code. I created jersey2-starter project on GitHub which can be used as starting point for your own production-ready RESTful service. In this post I’d like to cover how to implement and integration test your own validation constraints of REST resources.

Custom constraints

One of the issues which bothers me when coding REST in Java is littering your class model with annotations. Suppose you want to build a simple Todo list REST service, when using Jackson, validation and Spring Data, you can easily end up with this as your entity class:

@Document
public class Todo {
    private Long id;
    @NotNull
    private String description;
    @NotNull
    private Boolean completed;
    @NotNull
    private DateTime dueDate;

    @JsonCreator
    public Todo(@JsonProperty("description") String description, @JsonProperty("dueDate") DateTime dueDate) {
        this.description = description;
        this.dueDate = dueDate;
        this.completed = false;
    }
    // getters and setters
}

Your domain model is now effectively blured by messy annotations almost everywhere. Let’s see what we can do with validation constraints (@NotNulls). Some may say that you could introduce some DTO layer with own validation rules, but it conflicts for me with pure REST API design, which stands that you operate on resources which should map to your domain classes. On the other hand - what does it mean that Todo object is valid? When you create a Todo you should provide a description and due date, but what when you’re updating? You should be able to change any of description, due date (postponing) and completion flag (marking as done) - but you should provide at least one of these as valid modification. So my idea is to introduce custom validation constraints, different ones for creation and modification: 

@Target({TYPE, PARAMETER})
@Retention(RUNTIME)
@Constraint(validatedBy = ValidForCreation.Validator.class)
public @interface ValidForCreation {
    //...
    class Validator implements ConstraintValidator<ValidForCreation, Todo> {
    /...
        @Override
        public boolean isValid(Todo todo, ConstraintValidatorContext constraintValidatorContext) {
            return todo != null
                && todo.getId() == null
                && todo.getDescription() != null
                && todo.getDueDate() != null;
        }
    }
}

@Target({TYPE, PARAMETER})
@Retention(RUNTIME)
@Constraint(validatedBy = ValidForModification.Validator.class)
public @interface ValidForModification {
    //...
    class Validator implements ConstraintValidator<ValidForModification, Todo> {
    /...
        @Override
        public boolean isValid(Todo todo, ConstraintValidatorContext constraintValidatorContext) {
            return todo != null
                && todo.getId() == null
                && (todo.getDescription() != null || todo.getDueDate() != null || todo.isCompleted() != null);
        }
    }
}

And now you can move validation annotations to the definition of a REST endpoint:

@POST
@Consumes(APPLICATION_JSON)
public Response create(@ValidForCreation Todo todo) {...}

@PUT
@Consumes(APPLICATION_JSON)
public Response update(@ValidForModification Todo todo) {...}

And now you can remove those NotNulls from your model.

Integration testing

There are in general two approaches to integration testing:

  • test is being run on separate JVM than the app, which is deployed on some other integration environment
  • test deploys the application programmatically in the setup block.

Both of these have their pros and cons, but for small enough servoces, I personally prefer the second approach. It’s much easier to setup and you have only one JVM started, which makes debugging really easy. You can use a generic framework like Arquillian for starting your application in a container environment, but I prefer simple solutions and just use emdedded Jetty. To make test setup 100% production equivalent, I’m creating full Jetty’s WebAppContext and have to resolve all runtime dependencies for Jersey auto-discovery to work. This can be simply achieved with Maven resolved from Shrinkwrap - an Arquillian subproject: 

    WebAppContext webAppContext = new WebAppContext();
    webAppContext.setResourceBase("src/main/webapp");
    webAppContext.setContextPath("/");
    File[] mavenLibs = Maven.resolver().loadPomFromFile("pom.xml")
                .importCompileAndRuntimeDependencies()
                .resolve().withTransitivity().asFile();
    for (File file: mavenLibs) {
        webAppContext.getMetaData().addWebInfJar(new FileResource(file.toURI()));
    }
    webAppContext.getMetaData().addContainerResource(new FileResource(new File("./target/classes").toURI()));

    webAppContext.setConfigurations(new Configuration[] {
        new AnnotationConfiguration(),
        new WebXmlConfiguration(),
        new WebInfConfiguration()
    });
    server.setHandler(webAppContext);

(this Stackoverflow thread inspired me a lot here)

Now it’s time for the last part of the post: parametrizing our integration tests. Since we want to test validation constraints, there are many edge paths to check (and make your code coverage close to 100%). Writing one test per each case could be a bad idea. Among the many solutions for JUnit I’m most convinced to the Junit Params by Pragmatists team. It’s really simple and have nice concept of JQuery-like helper for creating providers. Here is my tests code (I’m also using builder pattern here to create various kinds of Todos):

@Test
@Parameters(method = "provideInvalidTodosForCreation")
public void shouldRejectInvalidTodoWhenCreate(Todo todo) {
    Response response = createTarget().request().post(Entity.json(todo));

    assertThat(response.getStatus()).isEqualTo(BAD_REQUEST.getStatusCode());
}

private static Object[] provideInvalidTodosForCreation() {
    return $(
        new TodoBuilder().withDescription("test").build(),
        new TodoBuilder().withDueDate(DateTime.now()).build(),
        new TodoBuilder().withId(123L).build(),
        new TodoBuilder().build()
    );
}

OK, enough of reading, feel free to clone the project and start writing your REST services!

I recently joined a team trying to switch a monolithic legacy system into set of RESTful services in Java. They decided to use latest 2.x version of Jersey as a REST container which was not a first choice for me, since I’m not a big fan of JSR-* specs. But now I must admit that JAX-RS 2.x is doing things right: requires almost zero boilerplate code, support auto-discovery of features and prefers convention over configuration like other modern frameworks. Since the spec is still young, it’s hard to find good tutorials and kick-off projects with some working code. I created jersey2-starter project on GitHub which can be used as starting point for your own production-ready RESTful service. In this post I’d like to cover how to implement and integration test your own validation constraints of REST resources.

Custom constraints

One of the issues which bothers me when coding REST in Java is littering your class model with annotations. Suppose you want to build a simple Todo list REST service, when using Jackson, validation and Spring Data, you can easily end up with this as your entity class:

@Document
public class Todo {
    private Long id;
    @NotNull
    private String description;
    @NotNull
    private Boolean completed;
    @NotNull
    private DateTime dueDate;

    @JsonCreator
    public Todo(@JsonProperty("description") String description, @JsonProperty("dueDate") DateTime dueDate) {
        this.description = description;
        this.dueDate = dueDate;
        this.completed = false;
    }
    // getters and setters
}

Your domain model is now effectively blured by messy annotations almost everywhere. Let’s see what we can do with validation constraints (@NotNulls). Some may say that you could introduce some DTO layer with own validation rules, but it conflicts for me with pure REST API design, which stands that you operate on resources which should map to your domain classes. On the other hand - what does it mean that Todo object is valid? When you create a Todo you should provide a description and due date, but what when you’re updating? You should be able to change any of description, due date (postponing) and completion flag (marking as done) - but you should provide at least one of these as valid modification. So my idea is to introduce custom validation constraints, different ones for creation and modification: 

@Target({TYPE, PARAMETER})
@Retention(RUNTIME)
@Constraint(validatedBy = ValidForCreation.Validator.class)
public @interface ValidForCreation {
    //...
    class Validator implements ConstraintValidator<ValidForCreation, Todo> {
    /...
        @Override
        public boolean isValid(Todo todo, ConstraintValidatorContext constraintValidatorContext) {
            return todo != null
                && todo.getId() == null
                && todo.getDescription() != null
                && todo.getDueDate() != null;
        }
    }
}

@Target({TYPE, PARAMETER})
@Retention(RUNTIME)
@Constraint(validatedBy = ValidForModification.Validator.class)
public @interface ValidForModification {
    //...
    class Validator implements ConstraintValidator<ValidForModification, Todo> {
    /...
        @Override
        public boolean isValid(Todo todo, ConstraintValidatorContext constraintValidatorContext) {
            return todo != null
                && todo.getId() == null
                && (todo.getDescription() != null || todo.getDueDate() != null || todo.isCompleted() != null);
        }
    }
}

And now you can move validation annotations to the definition of a REST endpoint:

@POST
@Consumes(APPLICATION_JSON)
public Response create(@ValidForCreation Todo todo) {...}

@PUT
@Consumes(APPLICATION_JSON)
public Response update(@ValidForModification Todo todo) {...}

And now you can remove those NotNulls from your model.

Integration testing

There are in general two approaches to integration testing:

  • test is being run on separate JVM than the app, which is deployed on some other integration environment
  • test deploys the application programmatically in the setup block.

Both of these have their pros and cons, but for small enough servoces, I personally prefer the second approach. It’s much easier to setup and you have only one JVM started, which makes debugging really easy. You can use a generic framework like Arquillian for starting your application in a container environment, but I prefer simple solutions and just use emdedded Jetty. To make test setup 100% production equivalent, I’m creating full Jetty’s WebAppContext and have to resolve all runtime dependencies for Jersey auto-discovery to work. This can be simply achieved with Maven resolved from Shrinkwrap - an Arquillian subproject: 

    WebAppContext webAppContext = new WebAppContext();
    webAppContext.setResourceBase("src/main/webapp");
    webAppContext.setContextPath("/");
    File[] mavenLibs = Maven.resolver().loadPomFromFile("pom.xml")
                .importCompileAndRuntimeDependencies()
                .resolve().withTransitivity().asFile();
    for (File file: mavenLibs) {
        webAppContext.getMetaData().addWebInfJar(new FileResource(file.toURI()));
    }
    webAppContext.getMetaData().addContainerResource(new FileResource(new File("./target/classes").toURI()));

    webAppContext.setConfigurations(new Configuration[] {
        new AnnotationConfiguration(),
        new WebXmlConfiguration(),
        new WebInfConfiguration()
    });
    server.setHandler(webAppContext);

(this Stackoverflow thread inspired me a lot here)

Now it’s time for the last part of the post: parametrizing our integration tests. Since we want to test validation constraints, there are many edge paths to check (and make your code coverage close to 100%). Writing one test per each case could be a bad idea. Among the many solutions for JUnit I’m most convinced to the Junit Params by Pragmatists team. It’s really simple and have nice concept of JQuery-like helper for creating providers. Here is my tests code (I’m also using builder pattern here to create various kinds of Todos):

@Test
@Parameters(method = "provideInvalidTodosForCreation")
public void shouldRejectInvalidTodoWhenCreate(Todo todo) {
    Response response = createTarget().request().post(Entity.json(todo));

    assertThat(response.getStatus()).isEqualTo(BAD_REQUEST.getStatusCode());
}

private static Object[] provideInvalidTodosForCreation() {
    return $(
        new TodoBuilder().withDescription("test").build(),
        new TodoBuilder().withDueDate(DateTime.now()).build(),
        new TodoBuilder().withId(123L).build(),
        new TodoBuilder().build()
    );
}

OK, enough of reading, feel free to clone the project and start writing your REST services!