CODEWITHSUNDEEP
androidiosxamarinxamarin.iosuitest
Radical Spin
Radical Spin

Reputation: 49

How to test everything in Xamarin

So i've recently started using Xamarin.UITest in my mobile application. Its great for testing the UI, navigation etc. However im slightly confused as to how the best way is to test all the other parts of the app i.e the database, web connection, model and so on. The project is cross-platform using a shared project.

Should these other tests be in along with the UITests or do they need their own separate project? Furthermore in Xamarin Studio on OSX is there a way to test particularly the .Net only code without having to build and launch the whole iOS app?

Thanks

Upvotes: 4

Views: 2199

Answers (2)

Dan Waters
Dan Waters

Reputation: 16

The main scenario that you're asking about is an integration test.

Since your tests drive the app from the UI layer, it's of course invoking all the code in the app and touching all the backend systems. But you're hoping to validate that the app and its supporting set of backend services all work correctly.

First of all, you'll need a way to expose data about your backend service to the test. You already did this, since the app probably uses a REST API and a database. For tests, you'd probably only want to do this for a staging or pre-production endpoint, somewhere that you won't be at risk for exposing real data by accident. You could configure a simple RESTful API that gives information about your backend services, and then invoke that from the test. You could also use backdoor methods which, in turn, call the API and prevent you from needing to make extra API calls from the test. Let's take a basic example, creating a new user.

Your test code might look something like this pseudocode:

var uniqueUser = Guid.NewGuid().ToString();
app.EnterText(firstName, "Test 1");
app.EnterText(lastName, uniqueUser);
app.Tap(createUserButton);
app.WaitForNoElement(e => e.Id("progress"));
app.WaitForElement(e => e.Text("User successfully created"));

// At this point, call your API using RestSharp or whatever makes sense for you 

string endpoint = "https://my.server.net/user/getByLastName/" + uniqueUser;    
var client = new RestClient(endpoint);
var result = ExecuteRequestHereAndItShouldReturnUserJSON();
Assert.IsTrue(result != null && result.FirstName == "Test 1");

That type of thing.

On teardown, you'd want to invoke a method to delete the test user by its id to avoid clogging up your database with test users created by the thousands of devices in Test Cloud. You could do this via backdoor or REST, whichever is safer depending on your current setup.

As for testing the code itself, just create a separate unit test project and use NUnit. There are a lot of great resources on testing listed in the other answer that can help you understand how to write good unit tests, when/how to use mocking, etc.

Upvotes: 0

Wosi
Wosi

Reputation: 45243

This question is really broad.

UI tests should only test the UI itself

  • Does navigation work correctly?
  • Is everything displayed like it should?
  • Are UI components visible, enabled, read-only etc.
  • Do components display correct data?

Your business logic should be tested in a unit test project

  • Do your classes process incoming data correctly?
  • Do they trigger the correct methods with the correct parameters in all cases?
  • Do they prepare the correct calls to webservices, databases or third party libraries? (You don't test the correct behaviour of other pieces of software here)
  • Do they throw exceptions as expected?

Unit tests are helping you the most to fix and avoid bugs. They are in general much more important for high quality code than all the other tests.

Integration tests are used to test the rest

  • Do databases, webservices, file system, operating system API work like expected?
  • Does it all work correctly together?
  • Does it all work fast enough?

There are many good books and links about good testing. It's way too much then to do it here.

Just a few examples:

With these links, StackOverflow and Google you will find out that your unit tests should stay in a separate project. Mock your business logic as good as possible in your UI tests. So that they don't test all your code. Otherwise you will result in UI tests which often fail in order to changes inside your business logic. You would have to change the UI tests everytime you change the unit tests. That becomes annoying and frustrating quickly.

Upvotes: 11

Related Questions