[
https://issues.apache.org/jira/browse/OFBIZ-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752541#action_12752541
]
Bob Morley commented on OFBIZ-2842:
-----------------------------------
Hi Phillipp,
This is very interesting; I have not experimented with calling simple methods
yet but I am sure it would be possible. What I mean by the "UtilResourceBundle
solution" is this -- when a service attempts to fetch a string from a resource
file, if the ofbiz container is not up and running an exception will be thrown.
Because UtilResourceBundle is a utility class of statics, there is no clean
way to mock out these method calls. So my solution was to make a slight
modification to the actual UtilResourceBundle so that I could actually
programmatically setup "resources" in the context of a unit tester. This setup
is typically just an empty collection so that the service gets the actual
resource key passed back and my unit tester can verify that an attempt was made
to get that key from a resource file.
In general, I think it is a bad coding practice to make changes to non-tester
code for the express purpose of making tests work. Usually the ability to
properly test code is a by-product of a clean design using patterns that
promote proper encapsulation and extensibility. These type of utility classes
will always be an issue to "mock" and they are not easily extensible; the way
that resources are retrieved is carved in stone. If I wanted to (for example)
retrieve resource values from the database, I have to replace the
implementation of the class as opposed to being able to extend the
implementation and plug-in this new implementation. Having said all this, I am
not suggesting that every utility class needs to be built in this manner there
are plenty of situations where that makes complete sense.
I think your issue with the transaction is another example of this. The
SimpleMethod instance does not provide an ability to use dependency injection
on the TransactionUtil class (a static class). So you paint yourself into a
spot where you either have to (potentially) include test code into
TransactionUtil or into SimpleMethod. There is no way to extend the
implementation of TransactionUtil to provide additional features or override
particular methods and my extension no way to leverage the mocking capabilities
to test difficult scenarios. For example, testing the handling of a timeout
exception on the begin method call in exec. From the unit testers point of
view it would be nice to not only know that we attempted to begin a
transaction, but we can force an exception and properly verify the handling of
that exception.
> Add mocked unit test framework
> ------------------------------
>
> Key: OFBIZ-2842
> URL: https://issues.apache.org/jira/browse/OFBIZ-2842
> Project: OFBiz
> Issue Type: New Feature
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Bob Morley
> Attachments: mockito-all-1.8.0-rc2.jar, OFBIZ-2842.patch
>
>
> Add the ability to create "true" unit tests -- ones that only test the
> confines of the method itself and using mocking techniques and dependency
> injection. This focuses the unit test on the actual code in the method and
> makes the assumption that other methods have been properly tested and will
> work. This does not suggest that there is not also value in unit tests that
> test more of an integration between components (such as a test that will
> actually invoke services using a the real dispatcher and manipulate entities
> with the real delegator).
> The goal of this will be to make it easy and very quick to test java-based
> methods (initial focus on services) along with not having to start an ofbiz
> container creating a suite of very quick method focused unit tests.
> I have attached a first pass at some of the base classes and a sample of a
> "mostly complete" unit test for the DateDimensionServices class (which has
> one method). Looking for feedback on this approach, potential for community
> collaboration, and potential buy-in. Some other things that are still to be
> done --
> - more samples
> - integration into ant build
> - solution to the "static worker" issue
> - UtilResourceBundle solution (I have it partially commented out)
> - easy verification of service interface adherence (servicedef existance &
> IN/OUT validation)
> - potential for GenericEntity get/set validation (verify entitydef adherence)
> (may not want to do this)
> - investigate potential for mocked simple methods
> - ant driven code coverage metrics
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
