I understand that in Moq, you need to set up properties before you can assign values. My question is why doesn't Moq just allow you to set properties by default without having to "set" them up.
That is a question for the developer. Till then you can take a look at the Quickstart and see if it helps answer your question.
mock.SetupAllProperties(); which stubs all properties on a mock.
My guess would be that not all mocks would possess properties so making the framework attempt to look up and setup properties would not make for an efficient API. the opt-in option of setting it up if needed seems like an optimal approach.
Related
Actually I am trying to structure my project in a clean MVVMV way. Unfortunately to this restriction I need to find a way to set pins to the map without the power DataBinding. One workaround could be to have the View in my ViewModel and set it directly.
Right now I don't have any chance to get the registered view. Does it make sense to extend the XLabs.Forms.Mvvm.ViewFactory?
Before adding a new issue on GitHub, my hope is that there is a better solution to handle such restrictions. I always used MVVM in my (small) WPF projects.
No that doesn't make sense. Your best approach would be to extend the Maps class to make Pins an ObserverableCollection that is bindable.
The new documentation format on the Xamarin site is rather difficult to read and does not provide the information you require at hand like it used to but I believe the Pins object is not bindable.
Take a look at the Xamarin Forms Labs Github project to get an idea of how this can be done. The approach is defined particularly well in the ExtendedPicker classes (here the items are bound to an ObservableCollection).
I'm developing an infrastructure for a major project currently based on caliburn 1.
It works fine but it seems like the future is in caliburn micro, am I right?
If I do, how do I implement filters? How do I specify view to a view viewnodel (non conventional)?
And whats the best place to put my splash logic (not root model)
I recommend moving to Caliburn.Micro as it's simpler and easier to extend. It is where any future innovations will be made and it has a larger more active community. As far as filters go, you can actually build them and plug them in. See here Marco's post You can add non-conventional view specification as well. You just plug into the view locator and teach it how to find views. For example, if you want to use an attribute, you can just have the locator look for that attribute first, use it if found, otherwise fall back to the default behavior. Regarding splash logic, you can do that by customizing the Bootstrapper.
I am looking at the Orchard source and am looking for where the IOchardServices gets its concrete injected. I realize that all one has to do is specify the IOchardServices as a param in a controller constructor and it'll get injected, but I want to know where Autofac actually does it. I was looking at '/Orchard/Environment/OrchardStarter.cs' and there are many builder..... calls and so it looks like injection is occurring there; did a search in that file for IOchardServices and didn't find it.
The reason I'm interested in this is, I need to do property injection on aspx pages' codebehind since our team will only be able to slowly migrate over to Orchard CMS and we'll need to keep our existing pages as is, well without too much modification. I also assume that when we have our own custom interfaces we'll want to inject and will need to know the best place to do this.
The actual injection is done within Autofac itself, not in the Orchard code. The autofac-configuration is done by several autofac-modules within Orchard-modules.
When you want to migrate to Orchard, you can just start by first using Autofac without Orchard. Define logical interfaces and put the Autofac-configuration in application_start in your global.asax. See here and here for examples.
Hey guys!
We used to write our UnitTests with FlexUnit and we were just testing our model. Now we want to test the view too. Before i run my tests i create an instance of my view and my model to test the stuff. When i try to access the view i get a null pointer exception. If i add the view to the displaylist it somehow works - even if i remove it from the list right after adding.
it looks something like this:
var myView: MyView = new myView();
//myView.initialize(); will throw error
Application.application.addChild(view);
Application.application.removeChild(view);
myView.initialize(); // will work
Hope you can give me a hint.
Sims
Flex UIComponents do not walk through the component lifecycle until after they are added to a container. As such, variables may not be initialized and children may not be created if you never add it to a container.
More info on the Flex Component LifeCycle. You'll notice there are 11 steps after the component is added to the container.
I suspect that adding it, then removing it, could cause other issues but it depends what you're trying to test.
To know your exact error, we'd have to see what code is in the initialize method on the view. Most likely it accesses a child that was not created yet.
MXML components will often masks the lifecycle steps, but a component will still go through them.
I hope this helps; but since you didn't ask a question I'm not sure if that was the information you were after.
In addition to what (www.Flextras.com) wrote, which I was just about to post as well, you might consider a different approach to testing your views.
First, consider a separation pattern like Presentation Model, MVP or MVC. They allow you to separate your view from your view behavior and test the behavior separate from the view. An approach like this, when done correctly, will take you a long way because you minimize or eliminate the AS3 code in your view.
If you really want to test your views, I would suggest that you use a functional testing tool for this. Unit test frameworks are good for testing classes in isolation. Once you start talking about views, which have complicated lifecycles, a functional testing framework starts to make sense.
Look at FlexMonkey as an example of a functional UI testing framework for Flex.
I recommend you to use User Interface Facade described here or here. This functionality is designed specially for UI componets testing.
We want to move our asp.net settings from web.config to a database. All of the examples I see for SqlSettingsProvider are Winform apps.
Can SqlSettingsProvider be used with asp.net?
If not, can someone suggest an alternative?
Thanks
According to MSDN the SqlSettingProvider attribute can only be used for classes derived from ApplicationSettingsBase. As this class is Windows Forms specific and this is stated explicitly in the documentation it means you cannot use this functionality in a web context. (See http://msdn.microsoft.com/en-us/library/8eyb2ct1.aspx for details).
To work around this and get similar functionality I would advise you to create a custom SettingsProviderBase class and implement the setting storage strategy that you need. Using this approach will also allow you to unit test the classes that are depending on application settings.