question about Test Cases

[benmartin101]

Let's say I plan on doing Integration Testing and Unit testing. Would I then have a separate Test Case for each type of test? One Test Case for Integration Testing and another for Unit Testing? And just to be sure, Test Cases are steps(instructions), inputs(that are to be used), and expected outcome, correct?

[disruptivehair]

Let's say I plan on doing Integration Testing and Unit testing. Would I then have a separate Test Case for each type of test? One Test Case for Integration Testing and another for Unit Testing? And just to be sure, Test Cases are steps(instructions), inputs(that are to be used), and expected outcome, correct?

If the tests you're doing in integration and unit are the same, then I'd say you can re-use your test cases. If they're different, then no.

Opinions among testers vary widely over terminology. What I would call a 'test script' might be called a 'test plan' by someone else. I wouldn't call what you're talking about a test case; I'd describe it as a script, but it doesn't seem to matter what the wider world thinks as long as people in your organization all agree on testing terminology.

[woodyz]

Let's say I plan on doing Integration Testing and Unit testing. Would I then have a separate Test Case for each type of test? One Test Case for Integration Testing and another for Unit Testing? And just to be sure, Test Cases are steps(instructions), inputs(that are to be used), and expected outcome, correct?Integration Testing and Unit testing test different qualities of the code. It would not be common for Unit testing to cover the same things that Integration testing covers. Therefore, it is not typical to find that the same tests are useful in both.

As it is commonly defined, the goal of unit testing is to isolate each part of the program and show that the individual parts are correct. The purpose of Integration testing is to test the correctness of how these individual parts interact.

I don't think there is a hard edge where we can say that one test can't be a part of both testing scenarios, but most of the tests that I do at a Unit level would have no purpose in Integration tests.

In many cases, Unit Tests cannot be complete unless there is a way to test methods that use other units as input. This seems like Integration testing, but when done correctly, the Unit tests would not actually use the other units, but would use Mock Objects. Mock Objects provide a way to have controlled input and interaction with other units, without actually using those other objects. There are numerous advantages to this - an important one being that you control the state of the Mock Objects in a way that would be impossible in integration testing - this allows you to do numerous tests with all kinds of potentially harmful scenarios very quickly and repeatably.

Anyway... I would suggest you won't be using the same "test cases" in Unit Testing as you would in Integration testing.

[disruptivehair]

Integration Testing and Unit testing test different qualities of the code. It would not be common for Unit testing to cover the same things that Integration testing covers. Therefore, it is not typical to find that the same tests are useful in both.

As it is commonly defined, the goal of unit testing is to isolate each part of the program and show that the individual parts are correct. The purpose of Integration testing is to test the correctness of how these individual parts interact.

I don't think there is a hard edge where we can say that one test can't be a part of both testing scenarios, but most of the tests that I do at a Unit level would have no purpose in Integration tests.

In many cases, Unit Tests cannot be complete unless there is a way to test methods that use other units as input. This seems like Integration testing, but when done correctly, the Unit tests would not actually use the other units, but would use Mock Objects. Mock Objects provide a way to have controlled input and interaction with other units, without actually using those other objects. There are numerous advantages to this - an important one being that you control the state of the Mock Objects in a way that would be impossible in integration testing - this allows you to do numerous tests with all kinds of potentially harmful scenarios very quickly and repeatably.

Anyway... I would suggest you won't be using the same "test cases" in Unit Testing as you would in Integration testing.

If it's proper unit testing, then you're right...he probably won't. However, a lot of organizations don't do proper structured unit testing. Sometimes a structured unit test doesn't really make sense and a lot of developers unit test their own code anyway. It's almost always integration where it falls over. :bigyello:

[woodyz]

If it's proper unit testing, then you're right...he probably won't. However, a lot of organizations don't do proper structured unit testing. Sometimes a structured unit test doesn't really make sense and a lot of developers unit test their own code anyway. It's almost always integration where it falls over. :bigyello:Good points! I think the best way for a developer to think about unit testing is that you are trying to devise tests at the smallest level possible. Long before modern NUnit/JUnit/XUnit style testing, one way we did unit testing was to place tests directly in the code module being tested. A public test method would be exposed, and inside this method each function call in the module would be tested directly. That is to say - each private as well as public method of the module could be exercised with a "suite" of tests that could test the correctness of the code. One very useful result of thinking this way is that you tend to refactor your code into small, single purpose methods that are testable. If you can have confidence in your code at this level, then it becomes easier to achieve integration. Now, I more typically use NUnit or JUnit or similar tools to do the same thing. I still write the "in class" unit tests, but not nearly as many since a lot of what that provided is more easily done with a unit test tool.