Sitecore Testing Tips and Tricks Part 1

Six ideas for effective Sitecore testing.

After being a part of many Sitecore projects, I have picked up some tips and approaches that help me test the solution. Below are six tips that will help you test more efficiently and look at your testing from a perspective that provides coverage based on how the solution will be used every day.

Test All the Ways to View the Page

There have been cases where a page or component would render in one scenario but not another. To account for this, it is important to test all the instances where a page or component could be viewed. In addition to the published page on CD, the page should also render on CM. Within Sitecore, the page should render as intended in both the Experience Editor and Preview Mode. You can have an error or an issue in any one of those four locations without that issue being present in another one.

Plan to Test in the Experience Editor

We all know there is more than one way to skin a cat, and in Sitecore, there is more than one way to perform most actions. Adding components is no exception. You can add a component through the Layout Details window in the Content Editor or it can be done in the Experience Editor. Using the Layout Details is not usually a viable option when Dynamic Placeholders are at work, but it is often the faster of the two creation methods. In the end though, the solution is being built for Content Authors who will be using the Experience Editor, unless otherwise intentionally called out. So, when testing components, we need to test the process the content authors will be using. That means asking if we can create a new component in the Experience Editor. It means asking if, in the Experience Editor, we can add a component that was previously created in the Content Editor. It is important to verify, not only the content creation process, but the specific creation process that the Content Authors will be using.

Planning to Add a Component Back Right Away? Don't Delete It!

There have been plenty of occasions where I have needed to add, remove, then re-add a component to debug an issue or work out something. You could go into the Experience Editor, delete an item, then re-add it, hunt down the data source, save and publish it. I don't care how fast your solution is running, that will take a minute. You could do a similar process in the Layout Details window, by opening the Control Properties to delete a component, then re-add it using the same process. Again, that will take a minute. A quicker alternative is to just open the Layout Details (Presentation tab > Details Icon), select the Final Layout, open the Component Properties for that specific component and add an "x" to the beginning of the placeholder. This causes Sitecore to not process/render the component, as the placeholder does not exist. Then when you are ready to re-add it, just remove the "x" and have it work again.

Raw Values Can Be Your Friend

Have you ever needed to create a bunch of test data to complete one of your test cases? Maybe you are looking to trigger pagination that appears after you add a certain number of links. Perhaps you are going to be using the same test image to fill out several components or image fields. If you go to the View tab and select the "Raw Values," you will see the GUIDs and all fields displayed as if they were a plain text field. This allows you to edit URLs or the path for a Media Item without needing to open the tool to do so. It also displays the GUIDs for selected items in pick lists or dropdown lists, which can be copied and pasted between components, or searched for a direct hit on the item in the Content Editor. It allows for RTEs to become a text field where you can past in text. After completing content author test cases this can be used as a method to create extra content or demo content, or as a workaround if a field is not working correctly. This should never be the primary means for editing items, but it is a good tool to have in your belt.

How is this process for the Content Author?

One thing to keep on your mind while you are testing is how this experience is for the content author. You may have a better working knowledge of Sitecore, or after working with a developer you may be able to add the component. How complicated was that process? If it was confusing for you, what would have made it less confusing? Or if it was difficult to edit in the Experience Editor, what would make that process easier? Discuss it with your team, but you may need to add a bug or an enhancement ticket to adjust the process for the Content Author.

The Little Things

There are little details that you, as the tester, are the first line of defense for. This largely ties into the previous tip, but here are some concrete things to check.

• When you added the component, is there a thumbnail image? There should be.
• If you create a component or a page in the Content Editor, are the insert options set up correctly? For example, if you have a link list component and the only possible child item is a link, then you should be able to insert a link to the list without having to do an Insert from Template and searching out the link template.
• When you add a component in the Experience Editor, can you edit the fields you should be able to?
• Are the page or component templates named appropriately, or could it confuse the Content Author when adding content?
• Are they located in a folder that makes sense?

By asking yourself these questions and getting them addressed, it can prevent a lot of headaches down the road.

That is just the tip of the iceberg when it comes to testing a Sitecore solution, so we’re going to have more coming soon. Check back in for some tricks on what to do when you just cannot find that component you know you published!