[Python-ideas] PEP 484 evolution

[Steven D'Aprano]

On Sun, Mar 20, 2016 at 01:29:36PM +1100, Chris Angelico wrote:
> On Sun, Mar 20, 2016 at 1:21 PM, Alexander Walters
> <tritium-list at sdamon.com> wrote:
> > I don't exactly see how stub files would be any different than tests in this
> > regard.  Unless I am totally misunderstanding something, the type hints only
> > exist to make static analysis by tools (presumably in a test suite) easier.
> > Why would a failing static analysis check go unnoticed and not the a test?
> > Why is there no argument to integrate the test suite into the module under
> > test, by the same logic?
> 
> There are - look at things like doctest. However, tests tend to be
> much longer-winded than type hints - even the most verbose of type
> hints - so the cost of keeping them inline is far higher.

In my experience, for every line of code I write, I will end up with ten 
lines of tests. Keeping *all* my tests in the same file as the code 
being tested would completely overwhelm the actual code. Nevertheless, 
it is appropriate to include some tests in place with the code:

- doc tests, as Chris mentions above;

- some applications may include a short "self-test" that the user can 
run from the command line to verify that it is working;

- we might consider assertions as a kind of run time internal 
consistency test;

- some languages have support for integrating tests in your code.

For example, Eiffel makes extensive use of Design By Contract for 
testing, with "require", "ensure" and "invariant" keywords.

https://archive.eiffel.com/doc/online/eiffel50/intro/language/invitation-07.html

Rust allows you to mark a function as test code by annotating it with 
the "test" attribute.

http://static.rust-lang.org/doc/master/book/testing.html

D can integrate the function and its unit test in the same piece of 
code:

http://dlang.org/spec/unittest.html

Cobra includes both contracts and in-place unit tests:

http://cobra-language.com/docs/quality/



-- 
Steve