Surveillance testing

We are far from being experts in testing but we detected a necessity and we did not know how to name it exactly.

While we were creating a library for an easy use of a web service, and you may find it hard to believe but we were using unit testing in its creation. Finally we agreed in the next points.

- The WS we are using is a risky item, due it was done by others for us, and the service might change, fail or degrade its performance.
- Unit testing should not use the WS, because it must be unit, isn't it?
- The testing we need is close to "system testing", but system testing aren't so prone to automatize, and the compilation of a library shouldn't depend on a test against a remote server.

With those and several more ideas, we thought of automate it through unit testing a series of tests, using our library, against the WS server, so we could monitor the server, its response times, its availability. So we will finally create a different project only to check the server, using our library, and potentially that project will be completed with other test for other dependencies.

There will be multiple pros with this approach, going further than a monitoring tool could reach.
- Development department scope, for those companies that look a battlefield.
- Unit test executed regularly with Jenkins, no more software needed.
- Sometimes providers make mistakes, we must know the sooner possible.

Result:
A new source empty project, with some unit test using our library, using the external web service, and checking it is ok. This project is inside our software cycle, using SVN, Artifactory and Jenkins, and it is scheduled for a midnight execution. If a test fails, an email will be sent telling us about it.
Now we talk about a new kind of test in our department :)

Keep learning!