<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Unit Testing on ilikeorangutans</title><link>https://kuelzer.ca/tags/unit-testing/</link><description>Recent content in Unit Testing on ilikeorangutans</description><generator>Hugo</generator><language>en</language><copyright>© 2026 Jakob Külzer</copyright><lastBuildDate>Sun, 12 Apr 2026 14:27:24 -0400</lastBuildDate><atom:link href="https://kuelzer.ca/tags/unit-testing/index.xml" rel="self" type="application/rss+xml"/><item><title>Grails 2 Testing Guide</title><link>https://kuelzer.ca/posts/2014/02/06/grails-2-testing-guide/</link><pubDate>Thu, 06 Feb 2014 13:59:40 -0400</pubDate><guid>https://kuelzer.ca/posts/2014/02/06/grails-2-testing-guide/</guid><description>&lt;p&gt;&lt;strong&gt;Note: I&amp;rsquo;m still working on this post, but I already use it as a reference so there&amp;rsquo;ll be more content over time.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;ve been quite busy at work with updating a Grails 1.3 application to 2.3.4. While writing a test harness it became apparent that lots of things have changed since I&amp;rsquo;ve last worked with Grails. Many changes are for the better, especially the integration of Spock framework. However, there were some issues that took me a while to figure out. The Grails docs on &lt;a href="http://grails.org/doc/latest/guide/testing.html"&gt;testing&lt;/a&gt; are comprehensive, but long. Here&amp;rsquo;s my cheat sheet.&lt;/p&gt;</description></item><item><title>The Case for Continuous Integration</title><link>https://kuelzer.ca/posts/2013/06/01/the-case-for-continuous-integration/</link><pubDate>Sat, 01 Jun 2013 13:59:40 -0400</pubDate><guid>https://kuelzer.ca/posts/2013/06/01/the-case-for-continuous-integration/</guid><description>&lt;p&gt;In my career as a software developer, I&amp;rsquo;ve come to appreciate the principles of Continuous Integration (CI). It forces you to do the hard things early and often and thus helps you reduce risk during development. It forces you to write tests, and be responsible about what you check in. All in all, good qualities and something that every development team should aspire to. Or so I thought. Reality is different, and so far almost every development team I have interacted with is deadly afraid of doing CI. So much, that there&amp;rsquo;s been near-mutinies because CI and what it means for team, causes so many problems. This is something that puzzles me, and I realize it might be because the teams in question don&amp;rsquo;t fully understand what CI is or only realize a subset of what it means. This is my attempt to demystify and explain CI.&lt;/p&gt;</description></item></channel></rss>