(Redirected by "J. B. Rainsberger" <jbrains@...
>So said jennybearcan on 2003-04-30 --------------------
>In general what are developers expected to do with failed test
>reports? Is the expectation that the error message should give all
>the information necessary to identify the bug?
>Or is it expected that the developer have knowledege of (or discover)
>what the test is doing? or run the test in debug mode? or other?
In my experience, it depends. Some defects are easy to diagnose. Some are instances of user error.
If you have Programmer Test coverage and QA still finds defects, then the programmers aren't using QA's tests, and they probably should. QA is automating the tests, right? (I hope so.)
If QA raises a defect, I ask the finder to work with me to reproduce it. I then isolate the cause, write the appropriate missing Programmer Tests, fix the problem and off we go.
>We are testing methods that take xml Strings as parameters and return
>xml. It would be nice to see what was passed in and what was returned
>if anything .. even when something like a NullPointerException is
>failing the test. Also we are running the tests in different
>environments so a developer may not see the same error if they run
>the test in the development environment.
This is not really a testing consideration. It's a logging consideration, and logging is important in enterprise-scale applications where it is usually impossible to run your tests at the client site. I would log information at the key handoff points between components. Within a component, there should be tests. Presumably you only need to know that XML strings are coming into a component because you fear that they are not what the target component expects. Consider using XML schema here to avoid the prob lem.
>Is a separate logging mechanism the answer?
It is, by the sound of it.