I'm trying to develop a custom DiscoveryClient but when it uses lb:// it doesn't work correctly. I have instatiated a DiscoveryClientServiceInstanceListSupplier using #Import(LoadBalancerClientConfiguration.class) in the application class.
Looking through the code there is notion of
this.serviceId = environment.getProperty(PROPERTY_NAME);
but whenver I debug it, I get null for that value.
Related
Finally having gotten GWT-Jackson-APT processors working and properly generating code for my classes, the one remaining hiccup I have is that for some reason gwt-jackson-apt uses the window JSON stringify (& parse) function.
$wnd.window.JSON.stringify(STRING)
The problem is that due to this being on a web-worker, $wnd.window is not defined. Even though JSON.stringify() is available in web-worker, the result is that the code won't run correctly, even though if I modify it to be just JSON.stringify() before uploading it works pefectly.
Is there a clean way to redefine which of these functions gets used in this instance?
What is the best means of going about fixing this so that my web-worker code doesn't try to call the functions that are not available in their context.
The library right now uses the elemental2 version of JSON Global.JSON.stringify
and if we look at the implementation of the JSON in the Global class we will find that it is assigned to the window instance here :
#JsType(isNative = true, name = "window", namespace = JsPackage.GLOBAL)
public class Global {
public static JSONType JSON;
}
when this is used as Global.JSON.stringify(someJsonObject) from GWT java code when compile it will produce $wnd.window.JSON.stringify(someJsonObject) or something very similar.
in order to fix this we need to access the native JSON in a different way that does not link it the current window instance.
one solution to this is to use JsInterop to interface directly with the JSON, something like this
#JsType(isNative = true, namespace = JsPackage.GLOBAL)
public class JSON {
public native static String stringify(Object jsonObj);
}
with this implementation we can use the JSON without the window prefix and when we use it in java like this JSON.stringify(someJsonObject) and notice how we no longer use the one from Global we end up with a generated Js that looks like this $wnd.JSON.stringify(someJsonObject)
i run a small test and implemented this JSON in the jackson-apt lib and switched to use the new implementation instead of using Global.JSON and all tests passed.
to me this looks like a good issue to be reported on the project repository. and i will apply the fix ASAP.
I'm writing a griffon application with JavaFX and the JPA plugin. I have a service I'd like to test - this service makes use of the JPA plugin (withJpa {...}) and it's this database access that I want to test.
So, I want to write this test so it inserts some data, then check that the service produces the right answer thus verifying the sql query is correct.
I've written a simple test:
class ReportServiceTests extends GriffonUnitTestCase {
GriffonApplication app
public void testStats() {
println app.getServices()
println app.getControllers()
}
}
but I cannot get hold of a valid service - both the println statements above produce "[:]".
How do I get hold of the 'ReportService' instance and exercise it against the database? I don't want to mock the database interaction.
Thanks.
There's no need to mock the database. As explained in http://griffon.codehaus.org/guide/latest/guide/testing.html#integrationTesting applications reach the INITIALIZE phase during integration testing. Addons get initialized during this phase. Services on the other hand get initialized lazily as they are pulled in by MVC members when instantiated: they do not get instantiated out-of-the-box if you call app.getServices(). However you can instruct the application to eagerly instantiate all services, this will make your code work as expected; just add the following flag to Config.groovy
griffon.services.eager.instantiation = true
More info on services can be found at http://griffon.codehaus.org/guide/latest/guide/controllersAndServices.html#services
I have a controller action that calls a model that fetches a JSON object from a web service. The JSON object is converted to a PHP object via a mapper class and used in my view.
What I'd like to do is to write a unit test that mocks the web service response, calls my mapper class to map the response to my PHP object and then uses that object in my view. This way, I can use assertQueryContentContains() to check to see if the values are being properly mapped to my object and populated in my view.
What is the best way to do this?
So far, I've got this in my unit test class:
$view->search_session = new Zend_Session_Namespace('search');
Zend_Registry::set('is_mobile', false);
$view = new Zend_View();
$view->setScriptPath(APPLICATION_PATH . '/views/scripts/');
$view->addHelperPath(APPLICATION_PATH . '/views/helpers');
$layout = Zend_Layout::getMvcInstance()->setLayoutPath(APPLICATION_PATH . '/layouts/scripts/')->setLayout('layout-internal');
$layout->setView($view);
$mapper = new ListingDetailMapper();
$listing = $mapper->map($this->_createMockListing(), new ListingDetail());
$view->listing = $listing;
$this->getResponse()->setBody($layout->render());
$this->assertQueryContentContains('h3.fn', 'Test Business');
The problem that I have with this is that I'm having to setup everything manually that would normally be setup in my bootstrap or configuration file if I were to dispatch the request normally.
Is there a way to inject my mock object into my view, so I can render the view automatically as it would if I dispatched the controller action using $this->dispatch()?
Or, should I somehow be mocking the model class that would normally return the web service response and somehow inject that into my controller?
It seems like I'm working a little too hard by having to recreate my environment as if I had called $this->dispatch(). Plus, it kind of defeats the purpose of testing if you aren't using the same setup code as you would in a real environment.
You need to decide what type of test this is. Right now it's trying to be a unit test. From reading what you say in your question,
it kind of defeats the purpose of testing if you aren't using the same setup code as you would in a real environment
it sounds like you want to be doing a system test.
If you want to do a system test then start using use dispatch() fully. You will have to automate your database/datastore to import and remove test data at the same time.
If you are trying to do a unit test then your view script is making it hard for you. The view script should not really be aware of the layout. If you can fix that then you can clean that code up. Your view script should not be aware of Zend_Registry. Don't forget Zend_Registry is just a global variable hiding behind a pattern name. I would also say it should not be aware of Zend_Session. Any of the data these classes provide should be either set by the controller or in a view helper. If you can fix those you can clean up that code.
There is also a fundamental principle to keep in mind, that the more dependencies a piece of code has, the more work it will be to set up testing for it. Right now your view script has a lot of dependencies and that is why it is more work to unit test it.
Is there any way to create a fake from a System.Type object in FakeItEasy? Similar to:
var instance = A.Fake(type);
I try to write a fake container for AutoFac that automatically return fakes for all resolved types. I have looked in the code for FakeItEasy and all methods that support this is behind internal classes but I have found the interface IFakeObjectContainer that looks pretty interesting, but the implementations still need registration of objects that is the thing that I want to come around.
As of FakeItEasy 2.1.0 (but do consider upgrading to the latest release for more features and better bugfixes), you can create a fake from a Type like so:
using FakeItEasy.Sdk;
…
object fake = Create.Fake(type);
If you must use an earlier release, you could use some reflection based approach to create a method info for the A.Fake() method. (since it's about auto mocking this shouldn't be a problem really).
This is best done using a registration handler. You should look into how AutofacContrib.Moq implements its MoqRegistrationHandler. You'll see that it is actually using the generic method MockRepository.Create to make fake instances. Creating a similar handler for FakeItEasy should be quite simple.
I've been going through the documentation for creating Prism applications and setting up the Shell seems to be split into 2 methods, CreateShell() and InitializeShell()
For CreateShell I simply have:
protected override DependencyObject CreateShell()
{
return ServiceLocator.Current.GetInstance<Shell>();
}
The documentation says that code is needed in the IntializeShell() method to ensure it is ready to be displayed. The following is given as an example:
protected override void InitializeShell()
{
Application.Current.MainWindow = (Window)this.Shell;
Application.Current.MainWindow.Show();
}
I have noticed however that if I omit the first line and just call the Show() method it seems to work (MainWindow already appears to have Shell assigned to it). Can you tell me why this is the case, and why we still need to explicity set the MainWindow property here?
Also as I did not specifically register Shell to an interface within the container, how is it able to resolve Shell in CreateShell()?
Question 1: Why does just calling Show() seem to work and why is Application.Current.MainWindow seem to be populated?
There are a few things you should check here. In a typical WPF application, the type for the main window can be specified in the App.xaml. If it is specified, WPF will instantiate one of those for you. This is not desirable because WPF won't use your container to instantiate your shell and any dependencies won't be resolved.
When you run that first line of code in InitializeShell, you'd be replacing the WPF-instantiated Shell object with the one you manually instantiated.
I looked at the code for the MEF and Unity bootstrappers and I don't see anywhere that MainWindow is being set, but I don't know if you might have customized the base bootstrappers, so that's something else to look for.
Show() works because you are simply showing the window you instantiated and the WPF-instantiated one isn't shown. This is my theory, but without seeing your code, it'd be tough to say for sure.
Question 2: How can Unity resolve something that hasn't been registered?
Unity can always resolve a concrete type, regardless of registration. It cannot resolve non-concrete classes that haven't been mapped to a concrete type. This is why Resolve<Shell> works, but Resolve<IMyInterface> doesn't unless you register a type.