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 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.

GetJava Download Button Logo
Support This Project