Frequently Asked Questions
This page lists general FAQs about junit-objects. If you have a question that is not covered here, please
contact the project directly.
- What exactly is junit-objects?
junit-objects (JO) is a framework for regression testing java objects and asserting design-patterns or
anti-patterns. JO is intended for use with both J2EE objects as well as Java SE POJOs (Plain Old Java
Objects). junit-objects is intended to replace all previous unit-testing frameworks including Junit.
- Is JO related to Junit in any way shape or form?
- What is regression testing or what is unit-testing?
Webopedia defines regression testing
and extremeprogramming.org describes unit
testing and its importance.
- What does junit-objects offer that other unit testing frameworks (like Junit) dont?
Lots of stuff, JO is a completely different approach to unit testing, focusing on objects and design-patterns
rather than method-call results. Take a look at the junit-objects Features page
for a detailed description including examples and comparisons.
- Does JO support Mock objects?
Yes, JO has sophisticated support for mocks called Magic Mocking. Magic mocks are mocks constructed
and injected by JO into your domain objects on demand. Magic mocks can have complex behavior and state, they
require very little configuration and NO java code whatsoever.
- Can I use other mock objects frameworks (like easymock) with JO?
I suppose you could, but it is strongly disadvised, as it draws away from JO's design philosophy of little or no
test code. In any case, magic mocks are much more flexible and easy to use and should be a logical choice with JO.
- Can I help with JO?
Absolutely, get in touch with the project. There are several
areas that need to be addressed, especially in design-patterns and UI.
- What inspired JO? Why did you create it?
The basic motivation was that there was too much time I spent writing test code and not enough of that time was
spent testing design. Also most of the unit-testing frameworks out there are procedural in nature, and I felt
that Java deserved a more object-oriented approach. I was also surprised by the lack of design-pattern specific
testing and discovery available outside of expensive tools (which are themselves often inadequate).
As for influences, Spring and
HiveMind are strong ones. Both encourage the use of structured XML bean and service descriptors that
makes reuse and redeployment easy. Both are also based on the dependency injection pattern, which is used heavily by
JO along with other general IoC (Inversion of Control).
Of course, Junit itself is a core influence. Much of the design of JO
ObjectTestCases is deliberately similar to Junit TestCases.