Help coderanch get a
new server
by contributing to the fundraiser

Tomek Kaczanowski

+ Follow
since Oct 26, 2005
Tomek likes ...
IntelliJ IDE Java Linux
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Tomek Kaczanowski

Hi John,

my question is about the "dark side" of BDD. What are the bad things related to it? What is annoying, hard, unpleasant?
10 years ago
Hi Jose,

I'm not sure what you mean by "GUI app" but I suspect, that the same solution that works for selenium web-tests might work for you. Please look for "selenium headless" and "selenium xvfb" to find out more.
12 years ago
Hi John,

what I would suggest, is to think about the "contract" your code has, and also about its breakable parts.

Take a look at this Survey class:

what things really deserve to be tested, what can a client expect from this class?

I would say that you should concentrate on the following:
a) after creation the isActive should return false (no matter which constructor was used - so you should probably write two tests here)
b) after creation the list of questions is empty (but not null!)
c) if shorter version of constructor was used, then the Survey should have ID = 0, and an empty title
d) if longer version of constructor was used, then Surver should have ID and titles as specified by parameters,

As for getters/setters it is not a bad thing that you try to test them, however one could argue that they are "too simple to break". I guess you haven't written them by hand but used some autogeneration feature of Eclipse (or another IDE). Thus the chances of invalid implementation are minimal. What I'm trying to say, is that you should concentrate on the responsibilities of the class, and NOT on single methods.

As for you question regarding how to test short and long constructors, I do not see what is the problem really. In one test method you create an object by using short constructor and then test its properties, and in another method you use longer constructor and also verify if it worked as expected. Not sure which part you are having troubles with.
12 years ago
Hi All,

congratulations to the winners! Thanks to all of you who participated and asked really interesting questions! Some of them really got me stuck for some time before I was able to answer (was I really able to answer them?).

BTW. If any of the winners is interested in ebooks then please specify which one would you like - the book is available in PDF (A4 and USLetter), ePub and mobi formats. And what is more, you can choose any number of them (e.g. ePub + PDF A4)!

12 years ago
Hi Paul,

your approach will work for simple cases. But even with such simple cases you would encounter issues, that can be easily avoided when using a mocking framework (Mockito or anything else). Please note, that your tests is tightly coupled with the implementation of two classes - ValidatePerson and Person. And this is one too many (Single Responsibility Principle for test code says that it should have "one and only one reason to fail") . You need to change your test code with every change made to Person's constructor. Using Mockito, such changes are completely irrelevant, and you don't have to change anything.

Things get much worse if you move from such simple cases to more complex ones. "Mocking by hand" approach will not be sufficient (and efficient) anymore. Consider the following examples (by collaborator I mean a class like Person from your example):

* a collaborator is an interface with many methods
* a collaborator is not a simple class with getters/setters (or fields set by constructors) - some values required by tests are computed within this class and you can not easily make collaborator return desired values (maybe the computed results depend on time, maybe on external web services, etc. etc.)
* a collaborator can throw many exceptions, which should be taken into account when testing all logic paths of the tested class

Yes, you could solve all of them writing mocks by hand but... do you really have time for this? Would you be happy with your tests code polluted with long implementation of interfaces (and remember you need few of them to test every possible scenario)? It would require many lines of code, and your tests would be very brittle - you would have to change them significantly if any change in collaborator class occurs.

Yes, you can do it by hand, but sooner or later you will write your own mocking framework to avoid pains related to testing of the scenarios mentioned above.
12 years ago
Hi Adrian,

you are right that currently available mocking frameworks are very similar in terms of what can be done using them.

The only pain I feel when mocking is that it makes my tests brittle by making them too tightly coupled with implementation. Mockito helps to avoid this to some extent by "not worrying about the unexpected", but even this does not solve the whole issue. Obviously, if you look at the general idea of verification of messages sent from tested object to collaborators, you will see that there is no much you could do - your tests simply have to repeat some of the implementation of the tested object. However there is still room for improvement when it comes to stubbing, as I learned few months ago.

To make long story short, a new framework - Komarro (based on Mockito by the way) - makes your expectations much less fragile. Usually in the tests you say something like (copied directly from Komarro's website):

but with Komarro you can write:

which means that the fact that SUT uses or maybe or anything else is not relevant anymore - the right person will be returned even if the implementation changes.

Is this the future of mocking frameworks? It definitely solves some issue with tests maintainability, which is a real pain, so I would expect this idea should gain some popularity.

Not sure if this is an answer to your question, but that is all I have right now.
12 years ago
Hi Paul,

paul nisset wrote:
From reading some of the other questions ,I understand that TestNG is meant to be sued as a replacement for JUNit .

Yes, exactly.

paul nisset wrote:
How does Mockito play into it ? Is it meant to be imported to create proxy objects to be used by the unit test ?
I'm not sure if I am using Junit correctly but I usually create a mock/proxy object of the class for each method I'm testing .

Paul, I don't understand what you mean by "proxy objects" in relation to testing. What Mockito allows you to do, is to replace real collaborators of a class, so during the tests we can:

* control their behaviour, in particular, control the values they return to the tested object (or make them throw some exceptions), which allows us to exercise all the logic implemented within the tested object
* verify that they receive specific, expected messages from the tested objects (or in other words, verify that some of their methods were called with expected arguments) - this allows us to make sure that the tested object interacts in the right way with its collaborators.
12 years ago
Hi Adam,

I would say that every kind of testing will give you a lot of experience. Unit tests will help you to write better code (better encapsulated, loosely coupled etc.), integration and end-to-end tests will teach you about tools (e.g. build tools, servers and databases) and automation, while end-to-end tests will add to this also a lot of experience with the technology you use to implement the interface of your application (be it HTML or webservices). Whichever path you choose there is plenty to learn - no doubts about it.
And the "fun factor" ...well, I feel great to see my whole application being automatically "clicked" by some GUI testing tool (like Selenium). But what makes you tick? I don't know.

Regarding the tools. The question is what language(s), tools and technologies you already use. How much freedom of choice do you have? Are you a lonely coder or is there a team that you should consult your decisions with?
Are you coding Java? Then maybe you could start with the tools that I have described in the book - mainly Mockito, TestNG (but also FEST Fluent Assertions and some other). Are you into other languages of JVM? Then maybe Spock or some Scala tools will be what you should start with. There are many good answers to your questions, but it all depends.
12 years ago
Hi Sumit,

the book shortly introduces BDD and discusses some syntactic sugar provided by TestNG and Mockito. BDD is not the main hero of the book.

I'm not sure I understood your second question - could you rephrase?
12 years ago
Hi Fredrik,

at first I wanted to answer with short "no", but after few minutes of head scratching I think there is more to say.

I think that Mockito is pretty complete, and there is nothing I miss there. Mockito gives you total control when mocking a well designed, loosely coupled code (but, as it was discussed in other thread ,it will not help you with mocking of final classes, static methods and such).

There is always room for improvement though! Recently I have found Komarro framework builds upon Mockito, and goes a step further allowing writing tests, which are even less coupled with implementation. Which means, that Mockito - currently number 1 - can be still improved.
12 years ago
Hi Rahul,

Rahul Dayal Sharma wrote:I am interested in learning Mockito and so would like to ask you whether your book requires any pre- requisite knowledge on that subject or in fact any kind of basics whatsoever. Also, like Kathy Sierra and Bert Bates, is your book written in a fun and unorthodox language or is it entirely technical, sticking to the concepts with a good number of examples/ demo to explain the concepts clearly.

In answer I will quote the book:

What I Expect From You:
In fact there is very little I expect from you, except that you are willing to learn, and ready not just to rethink your current ways of writing code but also to rethink (and maybe even reject!) things you learn from this book. Stay sharp! Question what you know and what you learn! Authors of books are sometimes wrong too!

Apart from having this attitude, you need to know at least the basics of Java (equivalent, let’s say, to a Junior Java Developer).

And btw. you can have no knowledge of unit tests at all.

As for your second question... well, this is not a comic book, definitely. It does contain a lot of code examples. Maybe you could take a look at the sample chapter (which is available on book website) and judge for yourself if the style suits you?
12 years ago
Hi Meena,

Meena Ajay wrote:Hi,
In my project Mockito and Junit are used for unit testing. In certain cases, a mix of mock objects and Autowired spring objects are used in combination for the tests.

I have some common resource which is being sourced using Autowired Spring beans and I have a sequence of test methods in the same test class.

The observation is that when the Junit tests on the class are executed from Eclipse directly , they execute properly. But when I run using the maven test command, i find that these tests run in parallel , and each test method is trying to source the same resource (Solace connection) and they fail.

I do not think I can help you with this specific scenario, but one thing that bothers me is what you say about parallel execution of tests via Maven. This is unexpected - as far as I know, the surefire plugin (which is what Maven uses to execute tests) by default does not use parallel execution (see surefire docs). Maybe it is misconfigured?

Meena Ajay wrote:On browsing, I found that there is not a straight forward way to execute the test methods in sequence by using some configuration in Junit (specify the order of test methods)

JUnit believes that dependencies between tests are evil. It is ok for the vast majority of test cases, however as you can see yourself sometimes it is not. Anyway, I do not think there is a way to force JUnit to do that, at least not without tweaking its runners or writing your own one.
And as for TestNG the answer is "yes, this is possible". In fact, this is one of the features TestNG offers, which makes it much more suitable than JUnit for tests other than unit tests (it is quite common for integration tests to rely on each other - e.g. one tests add something to database, the other relies on the fact that this thing is there). With TestNG you can specify order of execution in many ways, for example:
* you can say that method A should be invoked after method B
* you can say that method A should be invoked after a group of tests B is finished
* you can say that a test class A should be invoked after a group of tests B is finished
* and probably few more similar things which are described in TestNG docs
A word of caution - "invoked after" means only this that B will be invoked after A, but not necessarily immediately after A!

Meena Ajay wrote:Also is there a way to verify that static methods are invoked inside mock objects similar to how one can verify invocation of non-static methods to ensure that these methods are invoked on mock objects

Do you mean mocking of static methods? If so, please visit this thread
12 years ago
Hi Billy,

Billy Tsai wrote:How easy is it to introduce either TestNG or Mockito into a very large legacy codebase?

I really can't answer this question. First of all, I'm not sure what you mean by "introducing", second, adding new technology to your development environment depends very much on the quality of your code, software development process and devs skills!

Billy Tsai wrote:are there examples in the book to mix TestNG, Mockito with other frameworks such as JDummy and JMock? how can we utilize TestNG and Mockito with old test frameworks?

You can think of TestNG as a replacement for other testing frameworks (i.e. JUnit) and of Mockito as a replacement for other mocking frameworks (jMock, EasyMock). If you wish you could use TestNG with any other mocking framework, and you could use Mockito with any other testing framework. However, in the book I concentrate on working with TestNG and Mockito, because I believe that currently they are the most powerful and robust of all existing solutions.
12 years ago
Hi David,

I haven't used container testing for a long time, and I haven't (yet! even though I definitely plan to) used Arquillian, which seems to be a very powerful and useful testing tool (or more than this). Because of this, I do not want to pretend I can answer your question as it deserves to be answered. All I can say here is that, from different kind of tests that your application should undergo, Arquillian seems to address a very important and difficult part. It promises (and from what I heard also delivers) a way to test the integration aspect with a short feedback loop and in a very realistic environment (less mocking more real things).

Addressing your other question, I think that every application benefits from different kind of tests (unit, integration, end-to-end) but depending on the type of application the usefulness of each of these types vary. I can imagine some simple web apps being successfully tested with almost only end-to-end tests, and a complicated library with not much frontend which is tested by unit and integration tests.

Currently I test my applications on three levels:
* unit tests (with mocks) which verify business logic of classes
* integration tests (with Spring context and real database) - verification of things like correctness of database queries,
* end to end tests - applications set up with Cargo, database filled with data, real requests via user interface

12 years ago
Hi Ustad,

the book is available in print, and in various digital formats: ePub, mobi (for Kindle) and PDF (A4 and USLetter). You will find all details on the book site.
12 years ago