|
|
Stephen wrote:
> That’s right for each unit test you can and generally must prep
are the
> data the unit has to test.
That I knew. :-)
> You can run them in any order and since they are independent tests they
> do not rely on other tests passing or failing.
I can see situations in which a test would rely on other tests succeeding
.
You can't test "read from a file" if "open a file" fails, for example. An
d
if "open a file" fails in a way that leaves "read from a file" dumping co
re,
it can be messy to rearrange tests and still know what's failing.
--
Darren New, San Diego CA, USA (PST)
Human nature dictates that toothpaste tubes spend
much longer being almost empty than almost full.
Post a reply to this message
|
|
|
|
Darren New wrote:
> Stephen wrote:
>> That’s right for each unit test you can and generally must prepare the
>> data the unit has to test.
>
> That I knew. :-)
>
I know that you know ;)
{Quote from an old (60’s) Brit radio show :) }
>> You can run them in any order and since they are independent tests
>> they do not rely on other tests passing or failing.
>
> I can see situations in which a test would rely on other tests
> succeeding. You can't test "read from a file" if "open a file" fails,
> for example. And if "open a file" fails in a way that leaves "read from
> a file" dumping core, it can be messy to rearrange tests and still know
> what's failing.
>
This is where your expertise comes in and you create unit tests with
steps. For instance: (and I’m just guessing here)
UT 1 - Initialise Media Player.
Step 1. Initialise Media Player.
Expected Result: Media Player initialised.
Result:
Pass/Fail:
Comments:
UT 2 – Read File
Step 1. Open file.
Expected Result: File opened.
Result:
Pass/Fail:
Comments:
Step 2. Read file.
Expected Result: File read into buffer.
Result:
Pass/Fail:
Comments:
A spreadsheet is a better format. :D
--
Best Regards,
Stephen
Post a reply to this message
|
|