On 10/15/13 12:42 PM, Eb wrote:
On Tue, Oct 15, 2013 at 3:09 PM, Edwin Castro wrote:
On 10/15/13 11:42 AM, Eb wrote:
> Interesting perspective on contracts and the requirement to pass
> "correct" inputs (avoiding the use of the word valid here) to get
> correct results. How does a consumer know what is correct however?
A consumer must be told the specific semantics to expect. One way is to
read the code. In the absence of code you must rely on documentation.
Executable documentation in the form of code examples that also serve as
tests for validation is just one way to communicate the semantics.
So what's your opinion on what to actually do? What would the tests
look like?
What is appropriate for your team depends on your culture and the
requirements around how semantics are communicated between developers in
your team, developers in other teams consuming your work, QA, etc.
There are no fast rules, only principles and guidelines. Executable
documentation in the form of tests is preferable to traditional API
references or developer guides because tests have a tendency to break
when the documentation is out of date.
An acceptance test that validates that an exception is thrown and that
no side effects have occurred provides a way to explicitly document the
semantics of the method.
The specific exception validated by the test is perhaps not as important
from the test's perspective but we do want to provide valuable
information to the developers consuming our work so they can fix their
error.
An acceptance test that validates no side effects occur will alert us
when we accidentally break our documented semantics in a way that could
negatively impact consumers.
As others have mentioned, the client code should be responsible for not
passing you a null value. Your code is likely also client code for other
code so you'll need to make sure you are not accidentally passing nulls
to other code. This is an important quality to validate in unit tests.
--
Edwin G. Castro
