I have a fairly new C# application, approximately 6 months old, that we are now trying to incorporate testing into. (Should have been done from the start but I can’t change the past)
Parts of this application involve pushing some documents out to a folder. A third party application then picks these up, does its own work on them, and drops output files in another folder.
My application waits for this to be done, picks up the outputs, then continues its work.
This poses a problem when testing as I can’t really install another version of the third party just for testing, nor can I mock it without ending up fully rewriting the third party application.
How can I test these parts of my application? (Preferably with NUnit)
Specifically, I’m asking about how to unit test my code against the output of the 3rd party tool. So it’s a little bit different than another similar question, which involves isolating how code interfaces with a third party.
2
You may transfer existing (already processed files in previous runs) output files into the output folder just to simulate the work of the third party API in the unit test code. This will suffice if you are unit testing your own functionality and not the third party functionality.
1
Welcome to the world of integration testing.
The best way of approaching this is automated tools that can exercise your 3rd party app directly (if possible) or via a thin wrapper. You write a test rig to send various data in to the component, and inspect what comes out, preferably with some automated checking – eg run a regex on the file contents and see if it matches what you expect. In this regard its a lot like unit testing, except you need different tooling to check the results.
For the parts of your application that run the 3rd party component, you will still need to check that it works correctly. You might not be able to use the same unit test frameworks as you’ll need to check the reading of the data correctly, and for that you’ll need a file to read. I guess you could write a standard file in your unit test routines, but that seems like a lot of work for little results. Personally, I would keep a set of sample files and copy them in to the right place one at a time as you run tests. (mind you, I’d also run these as part of an external tool, rather than an “internal” unit test framework)
You can obviously unit test the rest of your program by wrapping the calls to the 3rd party in your own interface and mocking that at the cost of an additional layer of abstraction in your code.
It all depends of what you are trying to test. If you want to test only your own application because the 3rd party application has already been tested, then:
- Unit test the calls that creates data on the folder in a way that doesn’t really create these files (you don’t want to use file or database in unit testing). Anyway, if you use .NET, you already know that the saving of the file works (it’s part of the framework)
- Unit test the function that are called when the event of new file in the folder is triguered. Again, no needs for a real folder, juste inject already processed data to your function.
This will make a realy fast unit test of all your code.
But… If you want to test the interaction with the 3rd party or with the file system, then what you need is integration testing which means that you test all the parts that have already been unit tested and assert how they work together. This can be done with GUI automation software like Ranorex or if you software is triggered by event like “Is folder updated with new file?”, you can just do a .bat that do the trick.
Anyway, I know what I’m saying has been formulated with other words in other question but I think it was important to tell the difference between unit testing and integration testing.
Hope it helps!
You do unit testing by mocking the third-party component, so that you’re not checking the behavior of that component but rather just yours, and you do integration testing by including the third party component in the tests and checking that the whole ensemble works together. Neither precludes the need to do the other; while you want to carefully check that your part passes information around correctly, you still need to make sure that you’re not doing something daft that the other component doesn’t like (e.g., passing the wrong options or a badly encrypted password).
Be aware that integration testing is considerably more difficult than unit testing, as you need to check with an environment that is at least partially equivalent to a real deployment. (At the moment, I’m working with an application that is very difficult to automatically deploy, so our integration testing is an utter PITA as it can’t be tied in with our CI system…)
Your test should check if you push correct (whatever it means in your scenario) documents to correct folder.
Then check if you do what you supposed to when new documents appear in folder you monitor.
1