I encounter this problem quite frequently, so I thought I'd post one of my responses...
Okay, here is where I think you are going wrong, and when writing tests becomes hard, it’s usually because of this.There's nothing new here. Extreme Programming and various design patterns/best practices cover off all of this. But the usual philosophy holds here:
A nice way to code would be to:
- It’s important to layer your applications. Web/Services/DB – at least conceptually.
- What you have is a class that does everything. Web and Service. No-one can reuse your file processing logic without using the web, not even tests!
Now you say, “I've got this service that can process these files, but I need to access it via web services”. So, you write another class which is the web service – but it only knows about web things, and just calls the service so it doesn't know anything about processing files.
- Write a UNIT test that attempts to process a file. It passes in a file X and asserts that the result is Y. It won’t compile because you haven’t written the file processing code yet!
- Now you write the service which processes the file
- The test will compile and run now, but probably fail because you forgot something.
- Now you can fix your service
- And eventually the test will pass. You might think of more scenarios you want to add, so you create more tests.
It really depends on the resources you have available, and what make sense to test.
- Now, you may choose to write an INTEGRATION test which really only needs to test the WebService stuff – because you’ve already tested the excel processing code
- OR, you may choose to write a UI test which tests the deployed application
But what you end up with is re-usable and easily testable code. Which is good right?
If what you are doing seems too hard, its usually because you are doing the wrong thing.This is extremely relevant when considering testing. I've seen tests become extremely convoluted because the design was wrong. Test First Programming can help the design because you'll find bad (hard to test) code early. I've got much more to say about this, but I don't have the time right now!