Integration Testing for a Web App

Integration Testing for a Web App

If you need to do full testing including exploiting browser features like AJAX then I would recomend Selenium. Selenium launches a browser and controls it to run the tests.

It supports all the major platforms and browsers. Selenium itself is implemented in Java but that is not really an issue if it is being used to test a web application through its user interface.

Selenium tests are a sequence of commands in an HTML table, the supported commands are in well documented. There is also an IDE implemented as a Firefox plugin that can be used to record and run tests. However the test scripts created in the IDE can be used to drive tests against any of the supported browsers.

WebAPI app and integration tests in same solution

You could configure the WebAPI in a self-host. Then in your test fixture setup you will start the host and tear it down after each test. Then all your tests will be configured to hit the locally hosted API.

Scope of Integration Testing in a CI CD workflow

You're mixing Integration testing with System testing.

Integration testing checks that some components can work together (can be integrated). You may have integration tests to verify how does the Data layer API operates with a database; or how does the the Web API responds to HTTP calls. You might not have the entire system completely working in order to do integration testing of its components.

Unlike integration tests, the System tests require all the components to be implemented and configured. That is end-to-end testing (e.g. from a web request to a database record). This kind of testing requires the entire system to be deployed which makes them more 'real' but expensive.

How to integration test Azure Web Jobs?

While @boris-lipschitz is correct, when your job is continious (as op says it is), you can't do anything after calling host.RunAndBlock().

However, if you run the host in a separate thread, you can continue with the test as desired. Although, you have to do some kind of polling in the end of the test to know when the job has run.

Example
Function to be tested (A simple copy from one blob to another, triggered by created blob):

public void CopyBlob(
[BlobTrigger("input/{name}")] TextReader input,
[Blob("output/{name}")] out string output)
{
output = input.ReadToEnd();
}

Test function:

[Test]
public void CopyBlobTest()
{
var blobClient = GetBlobClient("UseDevelopmentStorage=true;");

//Start host in separate thread
var thread = new Thread(() =>
{
Thread.CurrentThread.IsBackground = true;
var host = new JobHost();
host.RunAndBlock();
});

thread.Start();

//Trigger job by writing some content to a blob
using (var stream = new MemoryStream())
using (var stringWriter = new StreamWriter(stream))
{
stringWriter.Write("TestContent");
stringWriter.Flush();

stream.Seek(0, SeekOrigin.Begin);

blobClient.UploadStream("input", "blobName", stream);
}

//Check every second for up to 20 seconds, to see if blob have been created in output and assert content if it has
var maxTries = 20;
while (maxTries-- > 0)
{
if (!blobClient.Exists("output", "blobName"))
{
Thread.Sleep(1000);
continue;
}

using (var stream = blobClient.OpenRead("output", "blobName"))
using (var streamReader = new StreamReader(stream))
{
Assert.AreEqual("TestContent", streamReader.ReadToEnd());
}
break;
}
}

How to properly unit test a web app?

Most of this is personal opinion and will vary from developer to developer.

  1. There are a ton of python libraries for unit testing - that's a decision best left to you as the developer of the project to find one that fits best with your tool set / build process.

  2. This isn't exactly 'unit testing' per se, I'd consider it more like integration testing. That's not to say this isn't valuable, it's just a different task and will often use different tools. For something like this, testing will pay off in the long run because you'll have piece of mind that your bug fixes and feature additions aren't impacting your end to end code. If you're already doing it, I would continue. These sorts of tests are highly valuable when refactoring down the road to ensure consistent functionality.

  3. I would not waste time testing 3rd party APIs. It's their job to make sure their product behaves reliably. You'll be there all day if you start testing 3rd party features. A big reason to use 3rd party APIs is so you don't have to test them. If you ever discover that your app is breaking because of a 3rd party API it's probably time to pick a different API. If your project scales to a size where you're losing thousands of dollars every time that API fails you have a whole new ball of issues to deal with (and hopefully the resources to address them) at that time.

  4. In general, I don't test static content or html. There are tools out there (web scraping tools) that will let you troll your own website for consistent functionality. I would personally leave this as a last priority for the final stages of refinement if you have time. The look and feel of most websites change so often that writing tests isn't worth it. Look and feel is also really easy to test manually because it's so visual.



Related Topics



Leave a reply



Submit