Sitecore Experience Edge is a multi-tenant system hosting tenants for a number of different Sitecore source systems. The data models of each source system are quite different which requires a different schema in the GraphQL API for each kind of source system. In this post I’ll be exploring the GraphQL schema used for XM tenants on Experience Edge. This schema is used by XM, XM cloud and managed cloud XM instances.
Experience Edge is a SaaS offering from Sitecore which allows users to publish content and retrieve it via a globally available GraphQL API. The service takes on the burden of scalability so you don’t have to. It provides a buffer between your content delivery applications (statically generated sites (SSG), server side rendered sites (SSR), kiosk applications, mobile applications, etc) and your headless CMS (Content Hub or Sitecore XM/XP) which allows the CMS to go offline for upgrades or maintenance without losing the ability to serve dynamic content.
This is the final post in my “Unit Testing Sitecore Components” series. In this series I’ve taken a seemingly simplistic Sitecore component and refactored it by applying several principals to make the code more reusable and testable. In this final post of the series I’ll recap the principals and provide a few resources to help explain them further.
In the previous posts of this series, I’ve refactored an existing Sitecore component to make it’s logic more reusable and prepare the component and the logic it includes for unit testing. In this post I’ll be writing the unit tests for the refactored EntryTaxonomy class, showing how to mock items and field values.
In the posts of this series so far, I’ve refactored a sample view rendering to make the rendering itself unit testable. In doing do I’ve extracted the business logic to a separate class which still needs some work before it can be properly tested. In this post, I’ll be covering 2 more principals to help with making Sitecore components more testable and reusable.
In the previous post of this series I detailed 2 principals which can help with making Sitecore components more testable and reusable. These were “keeping the business logic out of the view” and “keeping the Item class out of the model”. In this post I’ll detail several more principals to continue improving the code.
At the end of April (2020), I had the great pleasure of presenting at the virtual SUGCON conference online. My presentation was a live walkthrough showing how to unit test a Sitecore component. In the presentation I utilised many principals to refactor and improve a view rendering.
The Sitecore Item class is very flexible. But this flexability is a double edged sword. All too often, it’s tempting to simply pass items round your project API without creating a separate, explicit model. This can have performance implications when you need to scale and support 1000s of items.
Sitecore 9.0 introduces the evolution of xDB, xConnect. xConnect is a complete (almost) rebuild of the customer behavior collection and reporting capabilities of Sitecore (plus more). These capabilities are now delivered through a new set of separate applications. In this post, I’ll be introducing you to the Reference Data Service, which is a completely new capability that was introduced with xConnect.
Early this week I released Revolver 3.2. This release includes many small features I wanted to include in release 3.1, but I didn’t want to delay that release just to fit them in. But there is one major new feature, Sitecore 9.0 support. For full details, find the Revolver 3.2 Release on github.
Back in January I wrote an article about how to Roll your own Sitecore Item, which showed how to create an in-memory Sitecore item for use in testing. The technique was quite limited and still required some small config entry to allow everything to work (to create a Database instance). Well, Sitecore 8.2 has finally made a reality what so many of us have prayed for, for so long. We can finally mock Items and Databases with Sitecore 8.2. Though, it’s probably not quite as simple as you might hope.
A few years back, I uploaded a couple of short videos to YouTube to show how easy it can be to get started with testing your Sitecore solution. The approach shown in the videos uses my ASP.NET embedded test runner. I developed the first version of this test runner when I was first trying to test my own Sitecore projects, many years ago. The issue many developers face when trying to test their Sitecore solutions is trying to get the Sitecore code to run outside of a web/Sitecore context. What I managed to do with this test runner was flip the problem on it’s head; instead of trying to get the Sitecore code to work inside my unit test, I made my unit test work inside my Sitecore solution.
If there were a Mecca for Sitecore developers, it would likely be this place. Trekroner Fort. This famous Danish landmark welcomed many fresh-faced Sitecore developers and users as the default desktop background in Sitecore version 7.x and prior.
One of the most difficult aspects of unit testing against Sitecore is mocking Sitecore items. The Sitecore Item class is quite a complex class and it’s interface is not structured the way most mocking frameworks require. Mocking frameworks allow you to create dummy objects for use inside tests. But that’s not the only way to create dummy objects. One can always instantiate a class if the classes interface allows it. You might be surprised to learn that you can in fact create an instance of a Sitecore Item in your own code.