Testing Tridion implementation with Watir

A while ago my friend was telling me how they are testing their web application and he was really enthusiastic  about the Watir-library that they use. He told me that it makes writing the code for the tests a breeze and adding Cucumber into play makes the creating of the test cases possible for any non-techie. Obviously I had to try what all the fuzz was about.

Watiring Tridion

So what I decided to do was to try and automate some of the basic actions in Tridion. I wanted to build some kind of a Tridion-framework on top of Tridion that would provide easy access to the most commonly used actions and then write the test scripts on top of my own framework. Looking at the examples on the Watir-site I thought it was going to be a walk in the park. I should've known better.

Enough said I had some issues, some of them were solved, some of them weren't. The main problem I had was the excessive amount of IFrames and popups used in Tridion 2009 and some weird bugs in Watir/Watir-webdriver when handling both of those. I noticed that Watir-webdriver generally works better except that it is painfully slow to parse the contents of IFrames and in 2009 there were quite a few nested ones. You can see from the code that I tried to solve the problem by using the XPath and Nokogiri to interact with elements but it only solved it partially (it was faster but still slow). Tridion 2011 was a way easier to work with, with the exception of few dynamically generated IFrames due to a bug in ChromeDriver.

The second problem I had was getting past the authentication. Solving that took a lot of effort:

1. How to get past it without having to handle the pop-up --> Basic HTTP Authentication
2. Figuring why it's not picking the credentials, seems that browsers have security settings that by default they don't allow it, so how to get past it --> On Chrome an extension, on IE a registry key change
3. So how to load the extension to Chrome (ChromeDriver always loads a "clean" browser without any extensions or saved logins). I tried several ways to read the extension and this simple one worked in the end.
4. Tridion started throwing errors if the URL contained the credentials. Solution: reload the CME URL without the credentials as they are saved in the session.

In any case I managed to achieve my goal, I made a framework for the basic actions and some example scripts to show how to use it. It is far from perfect at the moment but I think it is quite cool that you can automate your browser to create some components for you, and with some additional work it can even create the schemas for them as well ;)

So your next question might be something like "Why would I need this? I can use Core Service to create components". Well, the answer is simple, with Watir you're testing the functionality of CME, in other words you're testing that your users see what they should see when they perform the same actions. For example, you can test that if a specific field (that is checked by Event System) has an invalid value the Event System throws a correct error message. Or you can test that when an user clicks on your GUI Extension he will see a correct pop-up and not some error messages. Automating these kind of tests can be a real life-saver when there are multiple people working on an implementation. You can pick up most of the problems as soon as they appear and not when somebody happens to find them.

Interested yet? Let's see how you can try this for yourself...

Installation of necessary tools

I presume that most of the readers are Windows-users, so I will describe the steps for installing the necessary stuff for that (and if you happen to be a *nix-user you probably already have Ruby installed and know how to use it).

1. Download Ruby 1.9.3 and Ruby DevKit from  http://rubyinstaller.org/downloads/
2. Run the installer for Ruby and extract the DevKit to some location (doesn't really matter where, I usually put it under Ruby/DevKit)
3. Follow the installation instructions for DevKit at  https://github.com/oneclick/rubyinstaller/wiki/Development-Kit
4. Update Rubygems with command "gem update --system"
5. Install Bundler with command "gem install bundler"

For editing the source-files you can use any text-editor. I highly recommend to try out Sublime Text 2. Since I tried it out I have used it for pretty much everything (HTML, JS, Java, Ruby, C++, Lua...). It's not free but it is well worth the money (the evaluation version doesn't have any limitations, but you should support good software), just keep in mind that it is not an IDE, it's a text editor and heck of a good one. If you don't believe me, just check some articles out there. And when you decide to install it, remember to get some useful plugins and to learn the most useful tricks.

Running the examples

Running the scripts is quite straightforward. Just clone the GitHub-repository and follow the instructions. Obviously you need access to some Tridion-environment to be able to see the scripts in action.

Tip: if you installed ST2 you can just open the whole directory of the repository and run the scripts straight from the editor by pressing CTRL+B (build system needs to be set as Ruby).

Creating your own scripts

The examples are quite simple so you probably want to create your own test cases and you probably want some documentation on how to do it. Well, unfortunately there is no other documentation available than the code itself. That is simply because I kept changing things daily so any documentation would've been outdated instantly. The other reason is that Ruby, Watir and the framework are so verbose that you should easily be able to figure out how to use the framework just by reading the example scripts. Or what do you think these lines do:

Looks simple enough, right? The only thing that you might wonder why it looks like you change the title twice, and the reason for that is simple. The first one changes the actual title of the component and the second one changes a user-defined called "title" (don't ask me why someone created a field named "title" in the schema).

Also the framework in its current state might not be enough for your needs so you might want to extend it. That might be little more difficult especially if you're a newcomer to Ruby and Watir, but I left a lot of commented code and comments to explain certain choices and to explain the more complex solutions so that should help you get started. If you decide to extend it I hope that you fork the repository and share your code as well!

What next?

So the obvious next step would be to extend the framework but what I personally find more interesting at this point is to try and plug in the Cucumber-framework to allow non-techies to write the test cases (or maybe I just want to see those nice green lines when running the tests ::think). I will definitely try and implement it at some point but you're free to contribute and beat me to it. (Hint: There are already good examples how to do it)

Ps. This is actually my first real program written in Ruby, so don't shoot me if I did something wrong :) All the feedback is welcome like always!

NetBiscuit linking solution updated!

Yesterday I updated the NetBiscuitLinking project at GitHub with the latest version. The biggest improvement is that the project now contains a TBB that handles the conversion from BML to correct ComponentLink-tags. Other than that it now supports cell-elements in addition of the three elements supported earlier. Instructions how to use these new features are covered in the ReadMe-file of the project so I won't cover them here.

What's next?

There are still some bugs/features to fix, for example I noticed that the RegEx for cell-element in the TBB doesn't seem to catch arbitrary number of attributes. Apart from the obvious bug fixing, I think the next big thing for the project is to create a Java-version of the extended ComponentLink. I've also been thinking about outputting TCDL-tags and creating a deployer extension to convert the tags to either Java or .Net controls depending on the selected target language. In my opinion that would make the solution feel more natural for Tridion (as that is how the normal HTML-links are handled) but on the other hand that would also require an extra step with the installation of the deployer extension.

Please let me know if you have any other ideas how to improve the solution!

2390 Lines of Templating

Today I actually finished something I've been planning to do for almost a year now. Well, at least almost. It still requires quite a lot of additional work to make it nice and clean. So what am I talking about? Of course about TOM.Net extension library/start-up kit/whatever you want to call it. Essentially it is a collection of useful methods and classes that Professional Services has used in several projects in the past years, even the good old TemplateBase is still there. Anyone who finds their code from the project feel free to boast in the comments below :)

In the beginning there was me, ReSharper and about 5000 lines of really messy code. Today after a few really efficient days I managed to clean that up into less than a half by doing some major refactoring and removing any methods that I deemed useless or implementation specific. While doing that I tried to make it as user-friendly as possible by dividing different functionality in specific classes so you should be able find what you need quite easily. Of course some of you probably don't agree with some design choices that had been made (e.g. some people hate extension methods and there are quite a few in this package) but then that's your cue to make it better ;)

This project is intended to be a starting point for any new TOM.Net projects. It is up to if you want to use it only as an example, pick up only the stuff you need or just build your project on top of it. I think it is especially useful for all the Tridion newcomers as it is packed with concrete examples. One thing to keep in mind that if you only reference to this project in your own one you need to put the DLL of this project in the GAC or use ILMerge to combine it with your own (it is a quirk of Tridion that it doesn't handle assembly references very well)

Also note that the project is still very much work-in-progress (just have a look at any class in Utilities, especially Navigation one) but I wanted to release this already as I have limited time to work on it myself. I hope some of you will pick it up, fork it and improve it. For example most of the extension methods are missing comments which I think could be very important for people not so familiar with TOM.Net.

So, without further ado here is the project. Please contribute and fork it!!

Ps. Sorry about a short and a bit messy post, I will write about some examples how to really utilize the project and to explain some design choices when I have some free time again :) Until then, please let me know any ideas and suggestions for the project!

Dynamic Linking with Tridion and NetBiscuits

Even though the biggest boom of must having everything mobile seems to have gone already there a lot of companies that want to build a new mobile web site. Sometimes you might even encounter a company or two that want a mobile website or an app just for the sake of it. I might write a separate post (=rant) about going mobile without having any strategy for it, but that's a story for a later date.

But now I'm getting side-tracked, the point today is how to utilize dynamic linking with your mobile websites when you're using Tridion and NetBiscuits. I'm going straight to the good parts so if you're just starting with NetBiscuits I suggest you start from here and there.

The Problem

NetBiscuits uses its own markup-language called BiscuitML (BML), in addition of that the RTF-fields in BML use a subset of BBCode to make things even more interesting. Neither BML or BBCode support the standard anchor-elements which the out-of-the-box Tridion-controls output. Using the standard controls actually results in malformed BML and breaking the whole page.

The (partial) Solution

Fortunately the solution is actually quite simple. The approach I took to solve this was instead of creating brand new controls I extended the existing Tridion-controls. The benefit of this is that you can use the same control for outputting the regular HTML-links as well as NetBiscuit BBCode or Link-elements. Also it means that if anything changes with the original control you can just recompile the project with the new DLL.

To use the new features just add an additional attribute "NetBiscuitLinkType" to the ComponentLink-control with one of the three values URL, URLNoFollow or Link (case insensitive). For example: You should use URL and URLNoFollow-attributes when you want to use your links inside RTF-fields (i.e. BBCode) and Link-attribute when you want an independent link (see BiscuitML-reference for more details). The output for each attribute:

Output with value "Url": "UrlNoFollow" respectively: ...And with value "Link":
Because you have to set the attribute to the control manually you still have to figure in which context the (dynamic) link is used. Fortunately, it is relatively simple, because you add the control-tags in your templates so in most of the cases you know if the link will be inside RTF-field or if it is used independently.

You can use simple RegEx to parse all the ComponentLink-tags and add the additional attribute to them that way (yes, go ahead, you can safely match the tags in the HTML with RegEx because they're not arbitrary, you won't be summoning any Great Old Ones). I will try to add some example TBB(s) how to do this part of the solution later on.

Where to get it?

You can grab the project from GitHub. At the moment it is only available for .Net and only handles Component Links.


Any suggestions and contributions are welcome!

EDIT: The project is now updated with a TBB to handle the conversion to ComponentLink-tags, see GitHub for installation/usage instructions

...but when I do, I do it in production

So, I finally gave up my fight against the masses and decided to create my first blog ever (I'm still fighting though, e.g. I don't have a Twitter account...but I'm quite tempted to get one). I also wonder if I should curse or thank my colleagues for encouraging me to start blogging (maybe they're the ones that will regret this later on), only time will tell.

First question probably is that what are you going to find from here. I wish I could tell you, I usually have more than a few things in my head that I want to write about (at the moment of writing this I have six drafts here and few coding projects waiting to be finished and shared) but my problem is that I always end up polishing them until end of times. I think it is safe to say that there will be code, a lot. Most of it is probably Tridion related due to my current job.

I guess the other part of the blog will be my thoughts about the software industry in general but in stereotypical Finnish way I'm a man of few words, that is, unless I'm ranting about something or if I'm having a few beers, so don't expect too much.

You can find some code that I've written from GitHub. I'm planning to provide full-blown projects there for any code samples I might share here (or other way around, base the code samples on some project I have in GitHub). If you're new to Git/GitHub then you should start from here and here. Suffice to say I selected GitHub because of the ease of contributing to projects so anyone interested in my examples can contribute or reuse my code. Unfortunately I haven't released a lot yet but I hope that I can get it growing considerably during this year.

I guess I should also explain the title of the post (and url of this blog). It all comes from the time I started with Tridion almost 2 years ago and was working on my first Tridion-project (at the time I wasn't working for SDL though). During one day I was demonstrating TOM.Net API for a customer and the first question I got was "So, how do you write unit tests for your templates?". Of course inexperienced as I was I answered without flinching something in manner of "Well, you just mock the classes and test your logic, just like you would do without Tridion". People with Tridion experience can probably guess how wrong my statement turned out to be...

As some people might know, I might be quite stubborn sometimes. And most of all, I'm not really one to accept defeat easily. So naturally ever since that occasion I've been on a never ending quest to prove myself right, that you can unit test your Tridion templates. My latest endeavor to solve this can be found in StackOverflow (Please contribute if you have any ideas!). I know there will be a beautiful day when I can finally write see that lovely green color of passing tests in my (Tridion) template code. On that fateful day I do not have to test my code in production anymore...

(For the nitpickers: Yes, you usually test your code in dev/test/acceptance/whatever first but I've seen cases where the input differs enough for the code to fail in production but not in others, so ultimately you test your code in production)

tl;dr: Hello World! Welcome to my first blog, Here I will be writing mostly about code (probably a lot is Tridion related due to my work). And if you're wondering, URL of the blog comes from the fact that I can't always test my code even though I really want to :(