Best Practice for Black Box testing [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

I have a couple of windows service applications that working with sql server. I would like to perform black box testing for my application. I don't want to use unit testing, because I haven't enough time to write test logic for all my methods. I just want to send requests to my application and check response from system and state of db.

Answer 1

Unit Testing an application is always recommended, but they are no help when it comes to "Black Box" / "End to End" / "Golden" tests.

Having said that, some of the principles of Unit Tests still apply to your task:

1. Automate the process - There should be no human involvement besides hitting "run".
   Use a dedicated platform for that - Teamcity is one of many.
2. Isolate all the tests - You should run any subset of them in any order, and get the same results.
   If you have a DB, run some script before and after every test, so that each test gets a clean environment (apply to all other statefull modules, like the file system, web cache, etc).
3. You might as well use a test framework (like NUnit), that already has built in Setup, Test and Teardown entry points, and call your setup script, your API, and cleanup script from there.

Answer 2

Black box testing is a style of testing - it does not relate to unit testing specifically. With black box testing you 'exercise' the public API of an object without using knowledge of the internal structure.

For black box testing think about covering all the possible classes of input and output (using equivalence partitioning).