<?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 Oxymoronical</title>
    <link>https://www.oxymoronical.com/blog/tag/testing/</link>
    <description>Recent content in testing on Oxymoronical</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 23 Nov 2011 20:15:52 +0000</lastBuildDate>
    <atom:link href="https://www.oxymoronical.com/blog/tag/testing/feed/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>How Crashplan breaks xpcshell tests on Windows</title>
      <link>https://www.oxymoronical.com/blog/2011/11/how-crashplan-breaks-xpcshell-tests-on-windows/</link>
      <pubDate>Wed, 23 Nov 2011 20:15:52 +0000</pubDate>
      <guid>https://www.oxymoronical.com/blog/2011/11/how-crashplan-breaks-xpcshell-tests-on-windows/</guid>
      <description>&lt;p&gt;I recently switched to a Windows laptop and have been going through the usual teething pains related. One thing that confused me though was that when I was running xpcshell tests on my new machine they would frequently fail with access denied errors. I’ve seen this sort of thing before so I know some service was monitoring files and opening them after they had changed, when this happens they can’t be deleted or edited until the service closes them again and often tests open, close and delete files so fast that there isn’t time for that to happen.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Changing the checkCompatibility preference</title>
      <link>https://www.oxymoronical.com/blog/2009/11/Changing-the-checkCompatibility-preference/</link>
      <pubDate>Fri, 06 Nov 2009 21:31:18 +0000</pubDate>
      <guid>https://www.oxymoronical.com/blog/2009/11/Changing-the-checkCompatibility-preference/</guid>
      <description>&lt;p&gt;Back in the mists of time I wrote some code to make nightly testers’ lives easier by giving them a simple preference to flip if they wanted to be able to install and use incompatible extensions. It’s been more than three years since then and the use of this preference has grown beyond its original use. It is now something recommended to regular users everywhere from forums to comments in news articles as a way to use their extensions in the new major Firefox releases.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Testing the background update checks</title>
      <link>https://www.oxymoronical.com/blog/2009/03/Testing-the-background-update-checks/</link>
      <pubDate>Thu, 19 Mar 2009 13:02:36 +0000</pubDate>
      <guid>https://www.oxymoronical.com/blog/2009/03/Testing-the-background-update-checks/</guid>
      <description>&lt;p&gt;Firefox does a fair number of things in the background to help keep things up to date. This includes checking for updates to Firefox itself, checking for updates to add-ons you have installed and checking for updates to a blocklist that disables known unstable add-ons. Normally it does these things quite happily, but for developers and QA, trying to verify that these background tasks are doing what they are supposed to can be annoying. After all who wants to leave Firefox running for a day just to see if it finds a new update?&lt;/p&gt;</description>
    </item>
    <item>
      <title>On Timezones, Testing and Deals with the Devil</title>
      <link>https://www.oxymoronical.com/blog/2008/03/On-Timezones-Testing-and-Deals-with-the-Devil/</link>
      <pubDate>Mon, 10 Mar 2008 16:04:18 +0000</pubDate>
      <guid>https://www.oxymoronical.com/blog/2008/03/On-Timezones-Testing-and-Deals-with-the-Devil/</guid>
      <description>&lt;p&gt;Timezones make my head hurt. Not the concept, that is easy, but writing code that works correctly in different timezones. Throw daylight savings correction into the mix and you’ll often find me in a corner rocking gently. The problem of course is that I frequently have to deal with data that isn’t just the standard unix timestamp (or various orders of magnitude away from). A number of times a load of information has been thrown away, never to be recovered which makes life interesting. You end up having to decide which is the best path to take when all of them are wrong in various ways.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Let the Testing Commence</title>
      <link>https://www.oxymoronical.com/blog/2007/08/Let-the-Testing-Commence/</link>
      <pubDate>Sun, 12 Aug 2007 06:38:49 +0000</pubDate>
      <guid>https://www.oxymoronical.com/blog/2007/08/Let-the-Testing-Commence/</guid>
      <description>&lt;p&gt;After a fair bit of work (feels like longer than 2 months) I’ve finally managed to get &lt;a href=&#34;https://bugzilla.mozilla.org/show_bug.cgi?id=382752&#34;&gt;bug 382752&lt;/a&gt; landed. What this gives us in simple terms is a set of functions that we can use in order to do unit testing on the extension manager. Alongside I have checked in the first unit test. Now if anything regresses &lt;a href=&#34;https://bugzilla.mozilla.org/show_bug.cgi?id=257155&#34;&gt;bug 257155&lt;/a&gt; we should know about it immediately.&lt;/p&gt;&#xA;&lt;p&gt;Ignoring the regression detection, I’ve always found unit tests to be fantastically useful when developing new code or fixing bugs. Zipwriter is a prime example, with a large number of tests that I can run by typing a single command I can test whether the changes I have made have solved the problem and not introduced any other errors.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
