I'm trying to set up and use Mockito into a GWT project, and I'm having trouble using it on the client side (in javascript). I tried to add a module and include Mockito, but it seems not to work (lots of errors). I also tried to do a full checkout from svn and integrate GWT in it that way, the same errors. How should this be done? Thanks.
GWT code tested with mocking framework (like Mockito) runs in JVM and no compiling to JavaScript, obviously. Thus, any JavaScript-related implementations should be mocked or stubbed using mock objects.
One architecture that receives wide adoption in GWT and that simplifies testing is MVP (variation of MVC). MVP places majority of meaningful functionality inside classes called presenters. Presenters do not rely upon GWT implementation classes but instead depend on GWT interfaces (mostly). Then Mockito is applied to mock/stub those interfaces to unit test presenter classes.
This blog is full of examples on both MVP in GWT and testing with mock objects (EasyMock).
And now there is https://github.com/google/gwtmockito which is probably what you need.
Without more specifics I can only say that mocking frameworks make heavy use of dynamic proxies and run-time code generation which will not be compiled by GWT.
Your best bet is using these mocks in plain JUnit tests.
Related
I have for long worked on EasyMocking in JUnits. I am pretty much comfortable with this but now I want to know how EasyMocks are different from Jmockits. I tried going through their documentation and I found out that the syntax is a bit different. But yet I could not figure out if there is any difference in their performances.
Can anyone help me figure out what are the points that make either of them better than the other? Is there any special element in JMockit that is not found in the other?
Thanks in advance...
There are many differences between JMockit and EasyMock/jMock/Mockito/PowerMock.
These are the major ones:
Support for integration testing: JMockit supports an out-of-container integration testing approach, similar to what the Spring Test module provides, but also supporting Java EE. The other mocking libraries only support isolated unit testing with mock objects.
A "faking" API (see also in xUnit Patterns), in addition to the mocking API. Each one of the other mocking libraries only have a mocking API.
Full support for "mocking", in addition to "mock objects". Other mocking libraries work with mock objects which they create and which need to be passed in somehow to the code under test. With EasyMock/jMock/Mockito, static methods, constructors, and "new-ed" objects cannot be mocked at all. PowerMock supports full mocking as well, but still focused on mock objects (specifically, new-ed objects must be "replaced" with mock objects through whenNew recording, while with JMockit a test can simply declare a #Mocked field).
Support for mocking/faking of final classes and methods. Only PowerMock also provides this support. Mockito recently added an "inline mock maker" which adds support for finals, but it's not active by default and may not be as reliable.
Support for mocking/faking of unspecificied subclasses and interface implementations (where the test only declares a base type to be mocked/faked).
In the mocking API, expectations on methods with multiple parameters can be recorded/verified with argument matchers (such as anyString, etc.) only for some parameters, while other mocking APIs require such matchers for every single parameter.
Also in the mocking API, expectations can be explicitly verified after the tested code was exercised, just like in Mockito. EasyMock/jMock do not support this verification model.
As for performance, mocking a type with JMockit (done through class redefinition) probably has a higher runtime overhead when compared to creating a mock object with EasyMock/jMock/Mockito (done through subclass definition), and lower when compared with PowerMock (done through class definition on a custom classloader). However, you should only notice the difference in performance if there is a lot of mocking being done, which most likely indicates overuse of mocking.
You can find a blog post about the differences between them (and also mockito!) here: http://www.baeldung.com/mockito-vs-easymock-vs-jmockit
While they all have different syntax and different ways of working, you should be able to achieve whatever you need in regards to mocking with either framework.
I'm in the middle of implementing a unit test infrastructure for a large C++ project, and due to political reasons I'm almost sure CppUnit will be pushed as the unit testing framework.
I'm trying to identify mock frameworks that blend with CppUnit. I've found mockpp, and I've heard that Google Mock should work.
What frameworks work alongside CppUnit?
Mocking libraries are typically independent of the unit testing framework. They accomplish two different jobs, and frankly don't have much reason to talk to each other. Where they do integrate is in answering these questions:
When should I create my mock objects?
When should I initialize the mock objects with my expectations?
When should I validate the mocks were called as expected?
And you do that at the appropriate points in your tests.
For one example, check opmock. http://sourceforge.net/projects/opmock/
According to their wiki, opmock is easily called from a CppUnit test. See http://sourceforge.net/p/opmock/wiki/Using%20Opmock%20with%20other%20unit%20testing%20frameworks/
I'm using Zend Framework in one of my projects and I'm using PHPUnit for unit testing. I know that Zend_Test_PhpUnit_ControllerTestCase class is good for testing controllers with its dispatch() method and all. But I also have a few simple classes like ones used for some calculations and so on. These classes do not require the entire Zend application to be bootstrapped and fired up to be tested.
So my question is should I extend my testcases from PHPUnit_Framework_TestCase class directly? Would it be a good development practice? Is it any good performance-wise?
One of the goals for writing unit tests should to be keep the code as clear, short and concise as possible. Tests are code too and need to be maintained in the future.
There is absolutely nothing wrong with using PHPUnit_Framework_TestCase directly for testing. Firstly because the whole testing framework is built upon it anyway. And secondly - since your simple classes do not contain controller logic, why would you include controller testing helpers then?
As for performance - I doubt the difference is even noticeable.
I've introduced visitors as one of core architecture ideas in one of my apps. I have several visitors that operate on a same stuff. Now, how should I test it? Some tests I'm thinking of are a bit larger then a unit test should be (integration test? whatever) but I still wanna do it. How would you test code like the C++ sample from wiki art on Visitor Pattern
Unit testing isn't really about testing patterns, it is about testing the correct implementation of methods and functions. The visitor pattern is a specific class structure, and for each of the classes (ConcreteVisitor and ConcreteElement, specifically) involved you'll want unit tests.
When you've developed confidence that your class methods are behaving OK, you could use your unit test framework to develop integration tests as well. Do not start integration testing rightaway: you'll find that you develop a lot of integration tests that are actually testing the behavior of a specific class, i.e. unit tests.
Whether you need mock objects or can use 'real' objects is a different matter. This depends a lot on whether the objects behave nice enough for unit test purposes (i.e. they do not pull in a lot of additional dependencies etc.), and whether the objects themselves are unit tested (i.e. you need to be able to trust these objects 100%). The mock vs. real objects issue has been addressed on stackflow before, so search the unittest tags.
make a test visitor object and make it visit things.... test that it visited the right things.
You can create mock objects and have your visitors visit them, and then create mock visitors, and test that the right actions were performed.
I am curious about how many of you folks incorporate mocking of objects (frameworks like JMock, NMock, RhinoMocks hand in hand with unit testing frameworks) into your daily development process. What are your experiences?
You see, I develop on top of a GIS (geographic information systems) platform, in which most of work pertains to some way of handling data. As its data object model is quite complex (many many classes and interfaces, all COM-based), it is also quite difficult and cumbersome to mock. In this case, mocking incurs a great deal of overhead when writing test suites. I wonder if there are people in similar situation, or just, how does mocking (in whatever situation you are in) work for you.
On a recent project that I worked on we used mock objects extensively in our unit testing approach. The project was 100% Java and moderately sized (about 100,000 lines of non-commented code). It was a Swing-based desktop application - and the only effective way that we found to test the user interface logic was through an MVC variant design that allowed us to use mock objects to substitute for the actual Swing user interface classes for the automated testing. We also used mocking extensively in the testing of our data access layer (Hibernate/DAOs).
In the user inteface use, the Mocks were easy and straightforward to build. And the design of the application (Fowler Passive View) easily incorporated mocks. This was not the case for the mocks used in testing the data access layer. But I can say that it was clearly worth the effort. In fact, most of the 'effort' really focused on coming up with a reusable solution that minimized the work that a developer had to do to create each individual mock. I'd recommend taking the time to dig into and discover an approach for your situation that allows you to easily mock up your GIS data layer. That - or just manually mock up each class. Either way the ability to run the automated unit tests that rely on the mocks is worthwhile...
In my situation mocks work really nice. But I'm using Python, which is so dynamic that it makes many things involving testing much, much easier.
In situation like yours, when application is mainly data-driven (as far as I see), mocks may not be as useful. Just passing data in and watching it come out should be enough for testing. I would just make sure that application is modularized enough, so this approach can be applied to reasonably small components.
Mocking can be useful in some kind of project. But, sometimes mocking is very time consuming and the ROI of it is low.
Trying to test Sharepoint it seems that mocking is the only way, and only typemock will let you mock sealed classes.
Mocking is used very extensively in my case. Mocks are usually for the classes that has external dependencies, e.g. network, database, filesystem. Any of these can introduce flakiness in the tests if mocks are not used.
If the mocks that you find costly to write because there are a lot of fake data to populate, you could set some pre-populated data objects as constants and use them or slightly modified copies in your test. If such data objects has external dependencies, then maybe refactor it in a way you can separate the two concerns.
There is an initiative started by Dave Bouman to try and build a community library of Mocks for use in ArcObjects related unit testing. His blog and this svn repository have great information related to unit testing GIS systems
http://blog.davebouwman.net/CategoryView,category,Unit%2BTesting.aspx
http://svn2.assembla.com/svn/arcdeveloper/TestingUtilities/trunk/