<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Testing on Hillel Wayne</title>
    <link>https://www.hillelwayne.com/tags/testing/</link>
    <description>Recent content in Testing on Hillel Wayne</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 28 Jun 2021 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://www.hillelwayne.com/tags/testing/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Cross-Branch Testing</title>
      <link>https://www.hillelwayne.com/post/cross-branch-testing/</link>
      <pubDate>Mon, 28 Jun 2021 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/cross-branch-testing/</guid>
      <description>This was originally a newsletter post I wrote back in December, but I kept coming back to the idea and wanted to make it easier to find. I&amp;rsquo;ve made some small edits for flow.
There&amp;rsquo;s a certain class of problems that&amp;rsquo;s hard to test:
 The output isn&amp;rsquo;t obviously inferable from the input. The code isn&amp;rsquo;t just solving a human-tractable problem really quickly, it&amp;rsquo;s doing something where we don&amp;rsquo;t know the answer without running the program.</description>
    </item>
    
    <item>
      <title>Property Testing with Complex Inputs</title>
      <link>https://www.hillelwayne.com/post/property-testing-complex-inputs/</link>
      <pubDate>Fri, 19 Jun 2020 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/property-testing-complex-inputs/</guid>
      <description>This was originally written as a tutorial for Hypothesis and will eventually be reproduced there, but it might still be useful for people using other property-testing libraries. This essay assumes some familiarity with Hypothesis. If you haven&amp;rsquo;t used it, a better introduction is here.
Once you learn the basics, there are two hard parts to writing property-based tests:
 What are good properties to test? How do I generate complex inputs?</description>
    </item>
    
    <item>
      <title>Feature Interaction Bugs</title>
      <link>https://www.hillelwayne.com/post/feature-interaction/</link>
      <pubDate>Wed, 05 Feb 2020 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/feature-interaction/</guid>
      <description>In most testing frameworks, you&amp;rsquo;re expected to write a lot of low-level tests and few high-level tests. The reasoning is that end-to-end tests are slow and expensive and only cover a tiny amount of the program&amp;rsquo;s state space. It&amp;rsquo;s better to focus on testing all the parts in isolation versus testing that they all work together.
In practice, global correctness does not follow from local correctness. It&amp;rsquo;s possible for every part to be individually rock-solid but the system to be broken as a whole.</description>
    </item>
    
    <item>
      <title>Finding Property Tests</title>
      <link>https://www.hillelwayne.com/post/contract-examples/</link>
      <pubDate>Mon, 08 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/contract-examples/</guid>
      <description>A while back I was ranting about APLs and included this python code to get the mode of a list:
def mode(l): max = None count = {} for x in l: if x not in count: count[x] = 0 count[x] += 1 if not max or count[x] &amp;gt; count[max]: max = x return max  There&amp;rsquo;s a bug in it. Do you see it? If not, try running it on the list [0, 0, 1]:</description>
    </item>
    
    <item>
      <title>Metamorphic Testing</title>
      <link>https://www.hillelwayne.com/post/metamorphic-testing/</link>
      <pubDate>Mon, 25 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/metamorphic-testing/</guid>
      <description>Confession: I read the ACM Magazine. This makes me a dweeb even in programming circles. One of the things I found in it is &amp;ldquo;Metamorphic Testing&amp;rdquo;. I&amp;rsquo;ve never heard of it, and nobody I knew heard about it either. But the academic literature was shockingly impressive: many incredibly successful case studies in wildly different fields. So why haven&amp;rsquo;t we heard of it before? There&amp;rsquo;s only one article anywhere targeted at people outside academia.</description>
    </item>
    
    <item>
      <title>Just a Whole Bunch of Different Tests</title>
      <link>https://www.hillelwayne.com/post/a-bunch-of-tests/</link>
      <pubDate>Mon, 02 Apr 2018 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/a-bunch-of-tests/</guid>
      <description>I&amp;rsquo;ve been working on a bunch of longform obligation pieces and while they&amp;rsquo;re a lot of fun, they&amp;rsquo;re also steadily driving me insane. So I took a day off to write about all of the kinds of automated testing I know about. I&amp;rsquo;m defining tests here to be &amp;ldquo;an independent verification program that, as part of verification, executes the code we want to verify.&amp;rdquo; This means types are not tests, as they don&amp;rsquo;t involve execution of the code, and contracts are not tests, because they&amp;rsquo;re not executed as an independent program.</description>
    </item>
    
    <item>
      <title>Property Tests &#43; Contracts = Integration Tests</title>
      <link>https://www.hillelwayne.com/post/pbt-contracts/</link>
      <pubDate>Sun, 17 Dec 2017 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/pbt-contracts/</guid>
      <description>I&amp;rsquo;m a pretty big fan of contracts and property-based testing. While they&amp;rsquo;re both powerful, they do have tradeoffs:
 Contracts are simple and allow for complex conditionals, but you need to test them over a wide space to confirm them. Property-Based Testing can test your code over a very wide search space, but you have to come up with good generators and invariants.  Maybe they complement each other: &amp;ldquo;your code doesn&amp;rsquo;t violate any contracts&amp;rdquo; counts as a PBT invariant.</description>
    </item>
    
    <item>
      <title>Why TDD Isn&#39;t Crap</title>
      <link>https://www.hillelwayne.com/post/why-tdd-isnt-crap/</link>
      <pubDate>Mon, 30 Oct 2017 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/why-tdd-isnt-crap/</guid>
      <description>After my recent vitriol about unit testing, a couple of people sent me Why TDD is Crap as a thorough debunking of TDD and unit testing. As someone very interested in software correctness, I ended up writing a debunking of his debunking. Transcriptions will be in quotes, my responses below. Some important notes:
 From what can tell, neither of us is using TDD in the &amp;ldquo;purest&amp;rdquo; possible sense of &amp;ldquo;write the bare minimum that makes the smallest unit test pass&amp;rdquo;.</description>
    </item>
    
    <item>
      <title>Unit Tests Aren&#39;t Tests</title>
      <link>https://www.hillelwayne.com/post/unit-tests-are-not-tests/</link>
      <pubDate>Thu, 26 Oct 2017 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/unit-tests-are-not-tests/</guid>
      <description>This is an absolutely insane idea and I&amp;rsquo;m delighted by its audacity so I&amp;rsquo;m sharing it with all y&amp;rsquo;all. There&amp;rsquo;s like a bazillion things wrong with it but saying dumb shit has never stopped me before so let&amp;rsquo;s do some grambling!
The way I see it, unit tests act as a frame around your coding. The most common practice is you write the tests to cover the return values and calls, write your code, and enforce that it passes the unit tests.</description>
    </item>
    
    <item>
      <title>Uncle Bob and Silver Bullets</title>
      <link>https://www.hillelwayne.com/post/uncle-bob/</link>
      <pubDate>Thu, 05 Oct 2017 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/uncle-bob/</guid>
      <description>A while back I wrote that Robert Martin was ruining software by being too good at programming. That was supposed to be a joke. Since then he&amp;rsquo;s done his damndest to actually ruin software by telling people they&amp;rsquo;re doing it wrong. His most recent response where he yells at software correctness was the breaking point for me, so I&amp;rsquo;m going to go ahead and say what many of us have been thinking:</description>
    </item>
    
    <item>
      <title>How Do We Trust Our Science Code?</title>
      <link>https://www.hillelwayne.com/post/how-do-we-trust-science-code/</link>
      <pubDate>Mon, 14 Aug 2017 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/how-do-we-trust-science-code/</guid>
      <description>In 2010 Carmen Reinhart and Kenneth Rogoff published Growth in a Time of Debt. It&amp;rsquo;s arguably one of the most influential economics papers of the decade, convincing the IMF to push austerity measures in the European debt crisis. It was a very, very big deal.
In 2013 they shared their code with another team, who quickly found a bug. Once corrected, the results disappeared.
Greece took on austerity because of a software bug.</description>
    </item>
    
    <item>
      <title>Hypothesis Testing with Oracle Functions</title>
      <link>https://www.hillelwayne.com/post/hypothesis-oracles/</link>
      <pubDate>Fri, 21 Jul 2017 09:00:00 -0500</pubDate>
      
      <guid>https://www.hillelwayne.com/post/hypothesis-oracles/</guid>
      <description>This post is about the Hypothesis testing library. If you&amp;rsquo;re unfamiliar with it, check it out! Property tests are a fantastic addition to your testing suite. All examples use pytest.
Imagine we&amp;rsquo;ve written a bubblesort:
def bubblesort(l: List[int]) -&amp;gt; List[int]: # blah blah blah  What are some of the properties we could test? We could check that the input has the same length as the output:
from hypothesis import given from hypothesis.</description>
    </item>
    
    <item>
      <title>Doctests in Python</title>
      <link>https://www.hillelwayne.com/post/python-doctests/</link>
      <pubDate>Thu, 16 Feb 2017 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/python-doctests/</guid>
      <description>Doctests are one of the most fascinating things in Python. Not necessarily because it&amp;rsquo;s particularly elegant or useful, but because it&amp;rsquo;s unique: I haven&amp;rsquo;t found another language that has a similar kind of feature.
Here&amp;rsquo;s how it works. Imagine I was writing an adder:
def add(a,b): return a + b  There&amp;rsquo;s two kinds of ways we can test it. The first is with unit tests, which everybody&amp;rsquo;s already used to.</description>
    </item>
    
  </channel>
</rss>