Is there a way to make EasyMock's #TestSubject annottation to work when the test subject object is enhanced with CGLIB?
Scenario: the #TestSubject object is a Spring bean which was enhanced with CGLIB in order to apply some aspect (assuming that for some reason Spring couldn't use JDK-based proxy). In this case, simply using #TestSubject and EasyMockSupport.injectMocks(this) does not really work. EasyMock injects the mock, however during execution the mock is not actually used due to how the internals of a CGLIB enhanced class work. In the end it is used the original reference the object had, not the mock.
The only approach I know is to create a setter in the test subject, and to inject the mock manually calling the setter. However sometimes I do not have access/permission/time to change the subject code to include the setter.
cglib classes are always final what prevents the creation of another proxy. This is therefore not possible to do. Rather, you would need to discover that a class is a cglib proxy already and rather enhance its base class.
Related
We're looking at moving our Integration Tests for our API to CakePHP's version of PHPUnit. We need to test that the returned values from the API are sane (valid JSON, etc...)
The helper methods on the IntegrationTestCase abstract class look really useful, allowing me to simulate requests by simply calling $this->get('/articles') or similar, but from what I can tell there's no way to actually read the response to one of these requests. Am I missing something?
It seems that without the helper methods provided by IntegrationTestCase it would be much harder to make requests. So what's my best option here?
I just realised that I can do this by simply accessing $this->_response. At first I didn't think I could do this because its visibility is protected, but then I realised that I can access it because my test inherits from IntegrationTestCase.
For a project I need to have a unique ID generator. So I thought about a Singleton with synchronized methods.
Since a Singleton following the traditional Singleton pattern (private static instance) is shared accross Sessions, I'm wondering if the #Singleton Annotation is working the same way?
The documentation says: Identifies a type that the injector only instantiates once.
Does it mean, that a #Singleton will be independent per User Session (which is bad for an id-generator)? Should I prefer an old school Singleton with Class.getInstance() over an Injection of an #Singleton-Bean?
Or should I use neither nor and provide the Service within an #ApplicationScoped bean?
it musst be guaranteed that only ONE thread, independent of the user session can access the method to generate the next id. (It's not solvable with auto-increment database ids)
Edit: JSF 2.2, CDI and javax.inject.* i'm talking about :)
All those kinds of singletons (static, #javax.inject.Singleton, #javax.ejb.Singleton and #javax.enterprise.context.ApplicationScoped) are created once per JVM.
An object that is created once per user session must be annotated with #javax.enterprise.context.SessionScoped so no, singletons will not be instantiated per user session.
Notice that there are two #Singleton annotations, one in javax.inject and the other in the javax.ejb package. I'm referring to them by their fully-qualified names to avoid confusion.
The differences between all those singletons are subtle and I'm not sure I know all the implications, but a few come to mind:
#javax.ejb.Singleton is managed by the EJB container and so it can handle transactions (#javax.ejb.TransactionAttribute), read/write locking and time-outs (#javax.ejb.Lock, #javax.ejb.AccessTimeout), application startup (#javax.ejb.Startup, #javax.ejb.DependsOn) and so on.
#javax.enterprise.context.ApplicationScoped is managed by the CDI container, so you won't have the transaction and locking features that EJB has (unless you use a post-1.0 CDI that has added transactions), but you still have lots of nice things such as #javax.enterprise.inject.Produces, #javax.annotation.PostConstruct, #javax.inject.Named, #javax.enterprise.inject.Disposes (but many of these features are available to EJBs too).
#javax.inject.Singleton is similar to #ApplicationScoped, except that there is no proxy object (clients will have a reference to the object directly). There will be less indirection to reach the real object, but this might cause some issues related to serialization (see this: http://docs.jboss.org/weld/reference/latest-2.2/en-US/html_single/#_the_singleton_pseudo_scope)
A plain static field is simple and just works, but it's controlled by the class loader so in order to understand how/when they are instantiated and garbage collected (if ever), you will need to understand how class loaders work and how your application server manages its class loaders (when restarting, redeploying, etc.). See this question for more details.
javax.inject.Singleton - When used on your bean, you have to implement writeResolve() and readReplace to avoid any serialization issues. Use it judiciously based on what your bean actually has in it.
javax.enterprise.context.ApplicationScoped - Allows the container to proxy the bean and take care of serialization process automatically. This is recommended to avoid unprecedented issues.
For More information refer this page number 45.
I am creating a stand alone camel application. I want to use only java (because the compiler tells whats wrong).
To make my code less coupled and reusable by tests i want to decouple the creation of context and registry to separate classes.
I just started to extend DefaultCamelContext - is this a good idea or should i extend/implement some other class?
Within this class i want to use my own registry (it binds some bean instances) class. I found method setRegistry(org.apache.camel.spi.Registry).
But how to implement such an registry? Is there also a "defaultRegistry"? (for tests there is an createRegistry(), is there something for outside the tests?)
At the end i want to use dependency injection (guice) to glue all stuff together: the registry will inject bean-instances, the registry is then injected in context and context is injected in my main-class than creates "main", sets context and "run()"s it.
Camel supports a pluggable registry strategy...so you should be able to implement the org.apache.camel.spi.Registry interface and call setRegistry(myImpl)...
there are several (Simple, Jndi, etc) registries that are supported that might meet your needs or serve as an example...
for example, here is the SimpleRegistry implementation class...
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=blob_plain;f=camel-core/src/main/java/org/apache/camel/impl/SimpleRegistry.java;h=d2a4a21c9f9fbc70f45fd485d1c46c8a20b9afea;hb=HEAD
If I have a data/web service that multiple view models need access to what is the preferred "MVVM way"?
Do I have a global static service or do I pass in an instance of my service to all my view models? I personally can't see an advantage of one approach over the other.
Passing in an interfaced version of your service allows your class to be easily unit tested. With global static state, this is not as clean or as easy.
Making the class take an interface also defines the contract for your class. You're essentially saying, "ClassA requires IServiceA and IServiceB to function correctly". With global static state, there is no such contract.
In addition to using Dependency Injection also consider a ServiceLocater approach, where each ViewModel would, if not passed an instance of a service, would call to the ServiceLocator to obtain an instance of the registered service at run time.
Fowler on DI and ServiceLocator
MSDN on ServiceLocator
I am working on a WPF application, using the MVVM Pattern.
Each ViewModel will need access to a security object, that essentially provides information about the rights the user has. Because this object only needs to be populated once at start up, and because populating it is (at least potentially) expensive, I want to keep it in state for the lifetime of the application.
I can make it a static variable in App, which would make it available to the whole application (at least that's my understanding). This would make my ViewModel implementations very difficult to test, since the App.SecurityObject call would be inline in each ViewModel. I would have to make sure App was available for each test and mock the App.SecurityObject call (I'm not even sure this would work, actually).
We are using StructureMap, so I could create a SecurityObjectProvider and configure a it with a Singleton lifecycle in the container, and simply make it part of every ViewModel constructor. The downside would be that (as I said) the provider would have to be part of every View Model constructor.
There are other, hacky workarounds I can think of, but they would involve creating methods (perhaps in the View Model base class) that would allow injecting the security object after instantiation for testing purpose only. I usually try to avoid this kind "for testing only" code.
It seems like this would be a common problem , but I can't find any SO questions that are completely on point.
Security concerns are often best adressed by Thread.CurrentPrincipal. If it's at all possible to fit your security concerns into that model (calling Principal.IsInRole and so on) that is by far the desirable solution.
It's pretty easy to unit test because you just need to set Thread.CurrentPrincipal before invoking the SUT and then make sure you revert it to its original value in the Fixture Teardown phase.
If Thread.CurrentPrincipal doesn't suit your need, I would suggest either an injected dependency or a Decorator that handles security. Security is often a Cross-Cutting Concern, so it is often preferable to handle it as declaratively as possible. In other words, if you can model it by Guards and Assertions, you don't need to actively call it, and you would be able to use a more AOP-like approach (such as a Decorator).
If that's not possible either, you can model it as an Ambient Context. This may look a bit like the Service Locator anti-pattern, but the difference is that it's strongly typed and has a Local Default that ensures that it never throws NullReferenceExceptions or their like because it protects its invariants.
The service locator pattern might help you out. You still implement the functionality as a service, but you have your VMs go through a static class to obtain the service, rather than have it injected:
var securityService = ServiceLocator.Resolve<ISecurityService>();
When running unit tests, you can configure your service locator to return mocks/stubs.
I think I would use some kind of Service Locator to get object. And in tests I would mock it out.