I am trying to set up my Xamarin.Forms application to use UI Tests. Currently the tests are working fine, but I would like to be able to mock or handle the API calls that the application calls, rather than the actual API calls being executed in the tests.
There appears to be a way that UITest can detect if it is running in Test Cloud, but I can't seem to find a way for the application to know if it is running tests locally. I am using an IoC Container to register the various interfaces that interact with these APIs, and would like the App constructor to be able to detect if it is running a UITest, then register the appropriate 'actual' interface instances or the 'mock' instances. Is there a known way to handle this?
Your issue can be solved in many ways, but this is what I actually do:
You can create a dedicated compiler configuration:
Then, based on the configuration you would manipulate your container boostrap pointing your interfaces to the mock objects.
Whenever you want to run UI tests you would compile this configuration instead of the release configuration.
Related
I want to start using the framework Spring Cloud Contract for contract testing. But does Spring Cloud Contract support JavaScript and JMS?
I haven't found any information about this.
As for the JMS, we do support it either via spring-integration or Apache Camel. You can also write your own JMS support. It's enough to register a couple of beans.
As for Javascript and non-jvm languages. There's no out of the box support but we have a process for that. The workflow is described here (in those cases the consumer is a Java app but in the next section I'll describe how the flow would differ) - https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract.html#_common_repo_with_contracts or https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract.html#_step_by_step_guide_to_cdc. We will try to obviously simplify the process but currently there's a bunch of manual tasks to be done (not very tedious though).
The consumer can very easily download and run the stubs. Just clone https://github.com/spring-cloud-samples/stub-runner-boot, build it and push the fat jar to your Nexus/Artifactory. This application will be used by the consumers to automatically download stubs and run them locally. As a consumer you can then call java -jar stub-runner-boot --stubrunner.ids="com.example.groupid:artifactid:classifier:version:8090" --stubrunner.repositoryRoot="http://localhost:8081/artifactory/libs-release-local" . That way the application will start, download the provided jar with stubs from the given address where your artifactory is. Now your front end application can call the stubs of the producer at localhost:8090.
Of course we will try to simplify the cloning and pushing process (https://github.com/spring-cloud/spring-cloud-contract/issues/37) etc. but for now you have to do those 2 steps manually.
UPDATE:
With this article https://spring.io/blog/2018/02/13/spring-cloud-contract-in-a-polyglot-world we're presenting a way how to work in a polyglot environment. It's enough to use the provided docker images to run contract tests against a running application and to run the stub runners too.
My asp.net application uses a resource file to point to some REST api endpoints. The apps behavior changes depending on the amount of data it gets back from those services.
I'd like to perform integration testing on my app but I'd like to use different resource files that have custom api endpoints depending on the scenario I'd like to check against. For instance, I'd like to be able to test the integration of my app if the end points return nothing, one item, or many items.
In my ninject bindings I have
var appSettings = StreamDeserializer.DeserializeFileFromResource<AppStartSettings>(Resources.appsettings);
Is there a way I can configure specflow to rebuild my application with a different resource file depending on the integration test scenario?
No, SpecFlow runs only when you execute your tests and so can not influence your build.
Could you parameterize in your code, which resourcefile is used so that it is decided at runtime?
Then you could write a step that changes this parameter.
How do I create integration tests when leveraging Xamarin.Forms?
Specifically, I do NOT want to rely on UI automation to test integration between the components of a system (i.e. database using SQLite).
I want my integration tests to target the layer beneath the UI.
For this I would recommend xUnit (there are others as well), that can test directly against PCL's. The native projects should be fairly empty and your ViewModels and Views should be void of most code, which means you can test directly on the Model and below.
Place a mock ISQLite DB connection to test the code without the SQLite DB, or place another one in that actually connects to a local SQLite DB, either way.
xUnit Project
https://github.com/xunit/devices.xunit
Though download the packages from NuGet, its easier. Then the test can also be run from VS which is a nice addition.
I have an ASP.NET MVC application with a separate project added for tests. I know the plusses and minuses of using the connection to the database when running unit tests, and I still want to use it. Yet, every time when I run the tests with the NUnit tool, they all fail due to my Data Context being null. I heard something about having a separate config file for the tests assembly, but i am not sure whether I did it properly, or whether that works at all.
i think you should check this discussion here, it should be related as i was having the same problem.
and how i solve my problem was just to copy my web config content to the app config inside he test project and voila, database connection restore and all is fine in the land of mvc again.
How are you creating your data context? How is it used in your action? Typically, it will use the database referred to when you set up the classes in the designer so you'd get a context connected to what you used for the designer which is, arguably, not what you want for unit tests, thus you add an app.config file to your unit test project and change the connection string to your test database. It doesn't usually result in a null data context.
I suspect that your unit test is simply not touching the code that creates the data context before you invoke the action method. Without code though, it's really impossible to tell.
I'm sure there's a simple explanation for this, but I haven't had much luck at finding the answer yet, so I figured I'd put the word out to my colleagues, as I'm sure some of you've run into this one before.
In my (simple) dev environment, I'm working with a handful of WCF Web Services, imported into my FB3 project and targeting a local instance of the ASP.NET development Web server. All good, no problems -- but what I'd like to know now is, What's the right way to deploy this project to test, staging and production environments? If my imported proxies all point, say, to http://localhost:1234/service.svc (from which their WSDLs were imported), and all I'm deploying is a compiled SWF, does Flex Builder expect me to "Manage Web Services > Delete", "> Add", recompile and release ever time I want to move my compiled Flex project from development to test, and to staging, and ultimately into production? Is there a simpler workflow for this?
Thanks in advance -- hope my question was clear.
Cheers,
Chris
If you have path names which will change depending on the enviroment then you will likely need to recompile for each environment since these will be compiled in the swf.
I typically use ANT scripts to handle my compile/deployment process when moving from development and production environments. This gives me the ability to dynamically change any path names during the compile. These build files can be integrated into Flex Builder making this process very easy once you have everything set up, and can be done with one click or scheduled.
Thanks Brett. I've been meaning to dig into automating my build processes anyway, so now's probably as good a time as any. :)
You do not need to build a SWF for each environment. Here's a technique I use commonly:
Externalize your configuration properties into an XML file; in this case, it could be a URL for each service or a base URL used by all your services
When the application starts up, make an HTTPService call to load the XML file, parse it, and store your properties onto some bindable "configuration object"
Bind the values from that object against your objects that depend on the URLs
Dispatch an event that indicates your configuration is complete. If you have some kind of singleton event dispatcher used by some components in your app, use that, so that the notification is global
Now proceed with the rest of the initialization of your application
It takes a little work to orchestrate your app such that certain parts won't initialize until steps 1-5 take place. However I think it's good practice to handle a lot of this initialization explicitly rather than in constructors or various initialize or creationComplete events for components. You may need to reinitialize things when a user logs out and a different user logs in; if you already have your app set up to that initialization is something you can control then reinitialization will not be a problem.