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.
Related
I have a single .NET Core .proj file and a single Google Cloud project. The .NET Core project is very simple with a single class implementing IHttpFunction and implementing HandleAsync which is the entrypoint. I have a Cloud Build trigger connected to this project's Git repository which is set to run whenever a commit is pushed into main.
I would like to have more functions-- and hoping to not duplicate common functionality between them -- add those functions to the same project. But when I have multiple classes implementing IHttpFunction, Cloud Build fails.
I think there are at least 2 other ways to do this:
Deploy manually and select a function - but can I do this with Cloud Build triggers too?
Have all functions go through a single "dispatcher" endpoint - which seems messy
What's a good way to do this?
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.
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.
So I have written a fairly simple DataAccess Layer for use with Umbraco CMS 4.9. I want to write some Integration tests to test that my repositories work etc.
Obviously Umbraco has some dependencies, so how do people test that their data access works normally?
p.s We already have BDD / selenium tests..I want proper Nunit Integration tests...
One approach might be to fake the source data, i.e. the nodes themselves. Obviously it would be a fair bit of work to set up a data tree, but because the Node object inherits from INode, you should be able to inject your own object implementing INode and create your own data tree for all the unit tests to use.
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.