<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>links.lmorchard.com - #tests</title>
    <link>/tags/tests/</link>
    <description>Recent bookmarks tagged #tests</description>
    <lastBuildDate>Mon, 02 Nov 2026 08:24:52 +0000</lastBuildDate>
    <item>
      <title>Verification-First Development • Buttondown</title>
      <link>https://buttondown.com/hillelwayne/archive/verification-first-development/</link>
      <description>before writing code, put in place some means of verifying that the code is correct, or at least have an idea of what you&#39;ll do.&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #dev #testing #tests #vfd&lt;/p&gt;</description>
      <pubDate>Tue, 18 Mar 2025 23:26:49 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:29616</guid>
      <category>dev</category>
      <category>testing</category>
      <category>tests</category>
      <category>vfd</category>
    </item>
    <item>
      <title>Write Code That Works by Reid Burke</title>
      <link>http://reidburke.com/2012/09/27/write-code-that-works/?awesm=reid.in_l6</link>
      <description>If you’re writing tests for code that’s rapidly changing, you’re going to spend more of your time writing tests instead of shipping features. For code that’s brand new, I typically only test-first a small amount of code and wait a while before hitting that green bar on a code coverage report.&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #code #imported:pinboard #tests #work&lt;/p&gt;</description>
      <pubDate>Thu, 27 Sep 2012 20:51:07 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:32672</guid>
      <category>code</category>
      <category>imported:pinboard</category>
      <category>tests</category>
      <category>work</category>
    </item>
    <item>
      <title>Write Code That Works by Reid Burke</title>
      <link>http://reidburke.com/2012/09/27/write-code-that-works?awesm=reid.in_l6</link>
      <description>If you’re writing tests for code that’s rapidly changing, you’re going to spend more of your time writing tests instead of shipping features. For code that’s brand new, I typically only test-first a small amount of code and wait a while before hitting that green bar on a code coverage report.&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #code #tests #work&lt;/p&gt;</description>
      <pubDate>Thu, 27 Sep 2012 20:51:07 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:22635</guid>
      <category>code</category>
      <category>tests</category>
      <category>work</category>
    </item>
    <item>
      <title>0xDECAFBAD</title>
      <link>http://decafbad.com/blog/feed</link>
      <description>self-link so as to play with bookmarking a feed&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #blog #feeds #filetype:atom #filetype:feed #mine #tests&lt;/p&gt;</description>
      <pubDate>Thu, 24 Jul 2008 21:39:25 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:11122</guid>
      <category>blog</category>
      <category>feeds</category>
      <category>filetype:atom</category>
      <category>filetype:feed</category>
      <category>mine</category>
      <category>tests</category>
    </item>
    <item>
      <title>Personal unit tests</title>
      <link>http://hober.backpackit.com/pub/1233865</link>
      <description>&#34;Basically, I’ve made a list of personal unit tests: assertions about myself that I’d like to be true.&#34;&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #goals #personal #productivity #tests&lt;/p&gt;</description>
      <pubDate>Mon, 24 Sep 2007 19:03:52 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:9662</guid>
      <category>goals</category>
      <category>personal</category>
      <category>productivity</category>
      <category>tests</category>
    </item>
  </channel>
</rss>
