<speedrack alt_text="Getting your plugins up to speed">
</speedrack>
Let's be real: testing is usually not the first thing on software developer's minds when creating a new system. I may or may not have been involved in a project or 2 like that in my day. And the "test driven development" that we tried to learn in the early days of programming didn't really prove much other than driving home certain coding styles. Curse you WebCat.... Not putting in a good word for your fellow felines.
However; as we get older, we learn from our mistakes. Namely the ones found in debugging. If you're reading this, you've already gotten to the wiser part, and jumped headfirst/feetfirst/behindfirst/bellyfloped into Jenkins, throwing some abandon in when taking up custom plugin development. You've also decided to go feet first since you're looking to test what you use for tests. Bonus points for keeping your plugin up to date. The way not to let the defect tide crash over your head is to get that core version up. My fellow crew, change your dependency to the plugin parent pom, and get ready for overall plugin improvements.
The tide of progress hides some interesting sandbars, and the first one you hit while paddling out of the shallows is Junit4. While I'm about ready to keep rolling in the deep with this ocean metaphor, I'm going to stay on shore and just let the cruse control of the new @Rule handle things for me.
Hot: JenkinsRule
Not: HudsonTestCase
Using the amazing powers of JenkinsRule, we are able to replace a lot of things one to one. I've included a good list of changes in the following gist. Check out the official Jenkins docs for extra unit test tips and tricks.
Along those lines, I found a few other snags that might need some extra explaining. Since the tests aren't a subclass of HudsonTestCase, you won't have the benefits of being a RootAction. But it's not an issue since JenkinsRule throws in this functionality too. Simply create a subclass of JenkinsRule, and customize away. Don't forget to move your resource into a subfolder for your custom JenkinsRule; check out this. Ex: /test/resources/com/example/UnitTest/hello.jelly -> /test/resources/com/example/UnitTest/CustomRule/hello.jelly
So while we definitely are out there running tests, acting all carefree, looking at the green checkmarks in GitHub, there's one last struggle you might hit in your tests: using a security realm. MockAuthorizationStrategy combined with setting JenkinsRule.jenkins.setAuthorizationStrategy(), you can easily throw together a whole system of permission for users. One of the best examples of this is cloudbees-folder-plugin/FolderTest.
Hopefully this helps with potential snags that you might run into when writing tests for your test framework. See you on the friendly IRC/Google Groups/GitHub PRs!
</sidebar>
