
“Tests should be poorly factored” - alecbenzer
This is a piece of advice I&#x27;d seen somewhere once, but can&#x27;t remember where (or if this is exactly how it was worded). Does anyone know of an article or something that talks about this, or a more well-known term for this idea?<p>The basic idea: Say you have some code like:<p><pre><code>  def square(x):
    return x ^ 2
</code></pre>
A test like:<p><pre><code>  def test_square():
    for inp in [3, 4, 5, 50, 100]:
      assert square(inp) == inp ^ 2
</code></pre>
is &quot;well-factored&quot;, in that it doesn&#x27;t have a lot of repetition, but isn&#x27;t a great a test, since it&#x27;s basically testing that the function&#x27;s code does what the function&#x27;s code does.<p>A better test would be something like:<p><pre><code>  def test_square():
    assert square(3) == 9
    assert square(4) == 16
    assert square(5) == 25
    # ...
</code></pre>
because, for one, it would expose the bug (^ is XOR in Python, not exponentiation).
======
tabhygfr2
I wouldn't call the first version well factored since "x ^ 2" is repeated. So
you could simplify to

    
    
        assert square(inp) == square(inp)
    

...at which point, if it's not 3:00 AM, you hopefully notice that it's not
actually testing anything and include both test input data and output data.

~~~
alecbenzer
I meant the test itself being poorly factored. But, even in that case, I'm not
sure realizing that square(inp) == square(inp) is silly would direct you to go
to manual input/output lists and not something like square(inp) == inp ^ 2.

This is of course a bit of a contrived, very simple example, so it might seem
silly, but I think you can imagine more complex functions where it's less
clear that "computing" the expected output in some way "cheats" the test.

