A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2019-March/156702.html below:

[Python-Dev] Tests for internal functionality

[Python-Dev] Tests for internal functionality [Python-Dev] Tests for internal functionalityTerry Reedy tjreedy at udel.edu
Sat Mar 16 17:23:30 EDT 2019
On 3/16/2019 3:10 AM, Ivan Pozdeev via Python-Dev wrote:
> In https://github.com/python/cpython/pull/6541 , I was requested to add 
> tests for an internal C function.
> 
> As I wrote in 
> https://github.com/python/cpython/pull/6541#issuecomment-445514807 , 
> it's not clear from the codebase
> 
> 1) where tests for internal (as opposed to public) functionality should 
> be located

In the same file where they would be if public, which is what you seemed 
to find.  Label somehow, such as 'class InternalsTest(TestCase):' or 
'test__private' (with double __ indicating test of _private).

>      * I only ran across very few tests for private functionality and 
> they were located alongside the public tests. See e.g. 
> https://github.com/python/cpython/pull/12140 -- site._getuserbase is a 
> private function.
> 
> 2) what spec one should test against since there's no official docs for 
> internal functionality

Is there an informal spec in the form of docstring or comments?  Besides 
that, test against current behavior.  The main purpose of retro-testing 
is to detect *unintended* changes of behavior (regressions).

> That time, they let it slide, but of course this is not something to 
> make a habit of. It still bothers me that I left unfinished business there.
> Any thoughts?

-- 
Terry Jan Reedy


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4