Confitura 2012 Been There, Done That

My relation from Confitura 2012 event.

No fluff, just stuff, so let us get to the point. And the point is, that there were many really good talks this year!

Cezary Bartoszuk had a very interesting talk devoted to CoFoJa (Java contract library) and yeti-test (random test framework). In fact this was my favorite talk during this event.
Cezary was very well prepared, and you could say he not really knows but also enjoys the subject. He was also very honest with his opinion about the contracts (during the talk and also later when we discussed things in smaller group). There were many questions during this talk and a lot of interesting discussion.

After this talk (and after reading a lot about contracts during last few years) I'm still not buying the idea of contract. I feel like this is kind of more powerful version of Java asserts which brings some duplication (I feel like I have to specify things twice - in contract and in tests). The only nice thing about it is that you can force developers who subclass your base class to stick to the contract your class promises (which basically means that LSP is not broken). However I feel this is a little gain for some substantial efforts.

The other idea - of random tests - is also on my radar for a long time (there was also an interesting talk by Dawid Weiss on Geecon'2012). I have seen many really stupid uses of randomness in tests, so I'm always eager to learn some valid ways to power test with randomness. However I'm rather skeptical to what I have seen today with yeti-test.
First of all a word of explanation to those of you who are not familiar with this tool. All it does is to run your code with many different parameters and see whether bad things (i.e. exceptions happens). In examples presented during the talk this tool found some bugs related to possible NullPointerException (when passing null to some methods) and ArithmeticExceptins (passing 0 and dividing by it). This is nice, but to be honest I believe it is a rather standard thing to have tests for border and unexpected values (nulls, zeros, empty Strings, empty collections, etc.) so I do not feel I need a tool for this. Secondly, I think that after I run this tool on my code (which I plan to do soon) I will discover a lot of such problems, but I expect most of them to be of no importance. What I mean by this, is that I believe certain validations make sense on certain layers, and I do not need worry about them in every method. Thus, I expect a lot of false positives. Well, will see about this.
To sum it up, I believe this tool have some uses, but still I would rather expect developers really think about possible test scenarios than to run some brute-force tool to do this for me. But why not use it after I implemented all test cases that I think are worth it? Well, I think it won't do any harm, so I'm gonna try it out.

After Cezary's talk, I went for "Clean Tests" talk by Jacek Kiljański. In general I enjoyed it, and I even support 95% of what was presented there, however there were some issues which I could not agree with. First of all, the idea of mocking everything is flawed (you shoulth not mockth collections!), second, there is too much ceremony and rules. In particular I disliked the idea of naming SUT's variable objectUnderTest (how much time it takes you to realise that the client variable is the SUT of ClientTest class?). Also I found some issues with objects creation (mocking everything + not using builders etc), and with idea of having a prepareStandardState method which sets SUT in "normal" state; and this method is reused within many tests. No.
After this talk we had a short chat with Jacek which let us better understand our points of view, which was nice.

I also enjoyed CoffeeScript talk by Andrzej Krzywda. I'm not into Ruby and hardly into web-games development, but I can tell that Andrzej really knows this subject and he gave a really interesting (and very technical) talk. What I remembered (and I should put it somewhere near my desk) is his opinion about frameworks: "we use libraries, but we do not allow frameworks to drive our applications". This is exactly what I learned some time ago from Gradle (Hans Docter coined a term frameworkitis to describe a situation when frameworks takes control). Also I liked how he explained how his team does design a game, in terms of decoupling client/server side, and keeping a game scenario as the core asset. This was really interesting also for general audience like myself.

Andrzej Grzesik had a talk about continuous delivery. This was interesting as Andrzej has a lot of experience in this area. There were some discussion, because people doubted whether they would be able to introduce such process to their software (for different reasons - both political and technical). Andrzej managed to answer these questions. What I liked was his remarks about convincing stakeholders (clients, higher-ups, admins) to continuous delivery. He stressed this few times and I couldn't agree more - obviously continuous delivery is not about technical solution, but also about mental change of all people involved in the project. What I was missing were some more information (examples of use) of tools that Andrzej mentioned. However all in all this was a good talk.
..ah, and I will probably remember this one idea that Andrzej mentioned: "if it hurts, do it more often". So very true not only in the domain of IT!

The conference ended with a keynote (or rather endnote) by Wojciech Seliga. Slightly controversial, but with passion (even anger which was not so nice from time to time). The talk was about "awesome" interviewees and interviewers. Wojciech, who works for Atlassian and also owns a company, has a lot of practice in hiring people, and he gave us a plenty of interesting thoughts. Thanks!

Great event!

In terms of organization I think everything was very good. Haters will hate, but frankly, for a free conference it was even much more than I had expected. A lot of drinks and food, everything nice and well prepared. Good job!

All I can say is that I really enjoyed the whole event and will surely be there next year! Long live Confitura! :)


I must agree with you that we should not mock everything. Maybe I was imprecise in my presentation, but what I meant, is that we should mock every more or less complex objects beside standard java.util classes like Collections and data structures.

As always, the problem of writting good tests is definitiely not a easy one, and we cannot show all aspects of it in just 45 minutes. I think that most of the programmers will find out quickly, that mocking collections is not good idea. Nevertheless the rule that we should mock almost everything else will be in their mind and less integration tests will be created.

As for the "sut", it is not a readable word and I find such a words very rarely in code. If every other word could be found in dictionary, why to put one, which could be not?

I was also on your presentation and I enjoyed it very much. There was a lot of interesting examples of code that should be enhanced. I also admire your talent of finding vivid, precize words for given problem.

You are doing great work with popularising writting good tests. Thanks!

Regarding "prepareStandardBehaviour()", it is my idea of keeping tests clean. It's still tested by me, but till now, I find it very useful.

lack of signature

Sorry for an anonymous post.

Best regards,
Jacek Kiljański


Hello Jacek,

thank you for your comment and for the kind words regarding my presentation! I hope to do it even better in the future. :)

I think the case of "mocking everything" is clear now. :)

Regarding "sut" - I do not promote such name of variable. I simply call my SUT's by class name, so I have "client", "product" etc. I haven't noticed problems with distinguishing which variable is THE SUT. It is usually pretty obvious based on the class name.

Tomek Kaczanowski

This used to be my blog. I moved to long time ago.


Please comment using