RE: Re: distinguishing between failures and errors

> -----Original Message-----
> From: Daniel Barclay  
> 
> 
...
> 
> Because tests aren't specifications. 
> 
> (How can a test show that the caller is responsible for not 
> passing in a null pointer?
> 

I disagree, how about:
        try{
            instance.someMethod(null);
            fail("someMethod should not accept null");
        }catch(IllegalArgumentException e){
            assertTrue("Client code should check for null arguments");
        }

> You can't test for any particular behavior from the callee
> if the callee's behavior in the face of a null pointer is 
> intentially left undefined (e.g., for flexibility in 
> implementing an interface).)
> 

The callee is the class being tested, the specifics for different
implementations could be implemented
in specific TestCases, inheriting from an abstract super class (that would
be the class coresponding to the interface).
If the point of the interface is to offer different implementations
(Strategy, performance) - in the sense of Map and HashMap/TreeMap - the
behavior in case of 
a null value should be similar.

> (How can a test show that a caller is responsible for not
> depending on certain current behavior of an implementation
> that is not part of the interface contract?)
> 

It can't, the caller's TestCase should do that. And possibly the callee's
documentation.

> 
> Because tests are code.  
> 
> (They have syntactic clutter that is necessary for use as tests 
> but which is just clutter relative to the information useful to a 
> client programmer.)
> 
> 
> Because tests, being code, can't relate code to external concepts.  
> 
> (A specification can say that a function f returns the mathematical
> sum of two given integers subject to the limitations of 32-bit
> signed binary arithmetic.  How can a test say something like that?)
> 

        try{
            int result = instance.f(Integer.MAX_VALUE, Integer.MAX_VALUE);
            fail("f should throw Exception when integer limits are met");
        }catch(IllegalStateException e){
            assertTrue("function f returns the mathematical sum of two given
integers subject to the limitations of 32-bit");
        }

> 
> Tests are great, but don't forget the documentation.
> 

AND they are great documentation. Ever tried to compile *.doc with the
source code to detect anomalies
in your documentation ?

> 
> It seems that some people who write tests waste one advantage of it:  
> 
> I agree that testing, especially writing tests even before 
> you implement, 
> is good because it forces you to think about what your code 
> is supposed 
> to do and how it's supposed to be used.  
> 
> Well, if you're already thinking about the contract, then that's a
> good time to document the contract.  
> 
> 
> Yes, I know this has to be modulated by what kind of code we're
> talking about (e.g., intra-program calls versus trans-API calls) 
> and by how stable the interface contract is.  I just wouldn't
> want to have to read test cases instead of Javadoc to figure 
> out how, say, Sun's Servlet API worked and was supposed to be 
> used. 
> 

Agreed, but it would be nice to have some coding examples too. 
For example setting/retrieving JNDI value in it's simplest form, then you
could 
easily test a JNDI setup/configuration.

> 
> 
> Daniel
>