Basic Introduction: Automatic Testing of SharePoint online using Cypress.io

In this article we will look at the Automated Testing tool Cypress.io and look at the basic requirements for being able to set it up to test against a SharePoint online list. There are some interesting nuances to look at but the basic pronciples hold true.

Introduction

Cypress.io is a front end automated testing tool which has been around for a couple of years but has received significant interest from the open source community. It is an electron based testing tool with significant advantages over using the long term front end testing defacto tool Selenium. There are some disadvantages as well (being Chrome only right now) but as modern web browers get closer and closer to parity, that is less of an issue than say 5 years ago. After talking to my react development friends at the Northwest JavaScript meetup I resolved to try and make it work.

There are other recommendations for automated testing including a great article from Elio Struyf which uses a combination of puppeteer and jest – but again I wanted to try Cypress.io. It was challenging !

Update: Sheer coincidence, Elio also published an article on Cypress today!

Authentication and SharePoint online

The Cypress.io engine is based on electron – which means it runs in node. This is very advantageous, in that it has the ability to use open source npm libraries as part of its run time. In this case it allowed me to use the node-sp-auth to be able to generate the necessary headers to access a SharePoint Online site as an authenticated user. For the sake of this example I had the username and password in the config – you probably want to look at encrypting that or soemthing 😉

Cypress tasks

Cypress.io has the ability to create custom tasks which will execute some node code. So I created a custom login capability using the node-sp-auth library. This code should be added to the index.js file in the root of the cypress code.

const spauth = require("node-sp-auth");

let getLogin = async () => {
  const username = "me@mydomain.org";
  const password = "********";
  const pageUrl = "https://mydomain.sharepoint.com/sites/HelloWorld";

  // Connect to SharePoint
  const data = await spauth.getAuth(pageUrl, {
    username: username,
    password: password
  });
  return data;
};

module.exports = (on, config) => {
  // `on` is used to hook into various events Cypress emits
  // `config` is the resolved Cypress config
  on("task", {
    // deconstruct the individual properties
    getLogin() {
      return getLogin();
    }
  });
};

 

Running the test

This code can then be referenced in the Cypress.io code to create the login headers necessary for authentication, before each of the tests are run. The waits are in here because I have to make sure the DOM is ready. It is a little clunky and I need to figure out how to do it better………

describe("Sample SharePoint List test", function() {
  beforeEach(() => {
    cy.task("getLogin").then(token => {
      cy.visit({
        method: "GET",
        url: "https://mydomain.sharepoint.com/sites/HelloWorld/Lists/CyList",
        headers: token.headers
      });
    });

    cy.wait(2000)
      .get(".od-TopBar-item")
      .wait(1000)
      .find('[name="New"]')
      .wait(1000)
      .click();
  });

  it("Should have a title of Hello World", function() {
    cy.title().should("contain", "Hello World");
  });

  it("Should have a validated Title value", function() {
    cy.get('[aria-label="New item form panel"]')
      .find(".od-TopBar-item")
      .wait(1000)
      .find('[name = "Save"]')
      .wait(1000)
      .click();
    cy.get('[data-automation-id="error-message"]').should(
      "contain",
      "You can't leave this blank."
    );
    cy.get('[aria-label="New item form panel"]')
      .find(".od-TopBar-item")
      .find('[name = "Cancel"]')
      .click();
  });

  it("Should submit the form with a minimum Title field", function() {
    cy.viewport(550, 750);
    cy.get(".ReactFieldEditor")
      .eq(0)
      .type("sample text");
    cy.get('[aria-label="New item form panel"]')
      .find(".od-TopBar-item")
      .find('[name = "Save"]')
      .click();
  });
});

Here’s how it looks

Running the test – we can see that cypress runs through each of the tests, waiting for the DOM to be ready…..(see below) and ultimately automated a Funcational test of the list. One of the REALLY cool things about Cypress is the ability to move back through the test and see what was executed at the time of the test. This allows the web developer to see the DOM state and everything, should their test fail!!

 

What I found about SharePoint

The modern SharePoint Framework, and more specifically the React JavaScript library on which it is based, uses Web Components to render the DOM. What this means is that the webpage itself renders aynchronously and at times under no control of my own, will re-renter itself as the page decides. This means that during the automated test, I came across multiple instances of where Cypress failed because the DOM elements were no longer attached. This is going to need some work on my part to figure this out……

Conclusion

You can use Cypress.io to functional test SharePoint online and SPFx – but there is clearly a lot more to learn 🙂

 

FIXED: SPFx HelloWorld build Errors preventing gulp build –ship: Browserslist: caniuse-lite is outdated

I recently came across the following erring during a HelloWorld build process – this was preventing my build from being able to ship.

 

PS C:\REpo\SPFest2019-1> gulp bundle –ship
Build target: SHIP
[17:27:17] Using gulpfile C:\REpo\SPFest2019-1\gulpfile.js
[17:27:17] Starting gulp
[17:27:17] Starting ‘bundle’…
[17:27:17] Starting subtask ‘configure-sp-build-rig’…
[17:27:17] Finished subtask ‘configure-sp-build-rig’ after 80 ms
[17:27:17] Starting subtask ‘pre-copy’…
[17:27:18] Finished subtask ‘pre-copy’ after 98 ms
[17:27:18] Starting subtask ‘copy-static-assets’…
[17:27:18] Starting subtask ‘sass’…
[17:27:18] Finished subtask ‘copy-static-assets’ after 203 ms
Browserslist: caniuse-lite is outdated. Please run next command `npm update`
[17:27:18] Finished subtask ‘sass’ after 416 ms
[17:27:18] Starting subtask ‘tslint’…
[17:27:19] [tslint] tslint version: 5.12.1
[17:27:19] Starting subtask ‘tsc’…
[17:27:19] [tsc] typescript version: 2.9.2
[17:27:24] Finished subtask ‘tsc’ after 4.54 s
[17:27:24] Finished subtask ‘tslint’ after 6.5 s
[17:27:24] Starting subtask ‘post-copy’…
[17:27:24] Finished subtask ‘post-copy’ after 318 μs
[17:27:24] Starting subtask ‘collectLocalizedResources’…
[17:27:24] Finished subtask ‘collectLocalizedResources’ after 5.15 ms
[17:27:25] Starting subtask ‘configure-webpack’…
[17:27:26] Finished subtask ‘configure-webpack’ after 1.43 s
[17:27:30] Finished subtask ‘webpack’ after 3.78 s
[17:27:30] Starting subtask ‘configure-webpack-external-bundling’…
[17:27:30] Finished subtask ‘configure-webpack-external-bundling’ after 998 μs
[17:27:30] Finished subtask ‘copy-assets’ after 50 ms
[17:27:30] Starting subtask ‘write-manifests’…
[17:27:31] Finished subtask ‘write-manifests’ after 1.51 s
[17:27:31] Finished ‘bundle’ after 14 s
[17:27:32] ==================[ Finished ]==================
[17:27:32] Project sp-fest-2019-1 version:0.0.1
[17:27:32] Build tools version:3.9.26
[17:27:32] Node version:v8.11.4
[17:27:32] Total duration:19 s
The build failed because a task wrote output to stderr.

Solution

The solution is not immediately obvious – because the use of the caniuse-lite browserslist is not part of my package.json. It is buried somewhere deep inside of the SPFx code provided by Yeoman.

The solution sof npm update did not work.

After a little googleing the following solved the issue – and taught me about npm update 🙂

npm update –depth 10 caniuse-lite browserslist

PS C:\REpo\SPFest2019-1> npm update –depth 10 caniuse-lite browserslist
npm WARN @uifabric/utilities@6.45.1 requires a peer of @types/react-dom@>=16.3.0 <17.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN ajv-keywords@3.4.0 requires a peer of ajv@^6.9.1 but none is installed. You must install peer dependencies yourself.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.9 (node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.9: wanted {“os”:”darwin”,”arch”:”any”} (current: {“os”:”win32″,”arch”:”x64″})

+ browserslist@4.8.2
+ caniuse-lite@1.0.30001015
added 2 packages and updated 3 packages in 29.744s

and that solved the issue.

 

SharePoint Framework workbench port (5432), is the same as default PostgreSQL db listener (5432)

As we discovered by mistake, if you are one of those people lucky enough to work in multiple technologies, sometimes you can end up hurting yourself and spending far too long trying to figure out why.

It turns out that the default PostgreSQL database port is 5432 – the same as the SPFx workbench.

Installing PostgreSQL causes it to run automatically on computer start. So there is already something listening on port 5432 and your workbench appears to not work as you wanted it to 😦

Anyway you have a few choices to get your workbench to work:

 

 

Office 365 CLI change affecting SharePoint online Build and Deploy

We saw this week that our build and deploy process for SharePoint Framework was breaking. We tracked it down to a change in the Office 365 CLI which was released recently.

Our previous step of logging into O365 so that we can deploy out package looked like this

#o365 spo login https://blahblah.sharepoint.com

The breaking change to the CLI was that they simplified the login process (makes sense)

https://github.com/pnp/office365-cli/issues/889

And now the command works without the spo precursor

#o365 login https://blahblah.sharepoint.com

 

 

Cannot find .scss module error – Enabling SASS integration with your SharePoint Framework code

When creating SharePoint framework webparts in Visual Studio code, out of the box integration with SASS files (.scss) does not work. You get errors which look like this (when you’re using ts-lint that is).

This also causes pain and angst when it comes to running CI / CD in Azure DevOps and the build breaks because npm test wont run – the enzyme rendering of the component wont work because it cannot find the scss file.

Natively, typescript does not understand scss as an import and you need to let it know that it’s ok to include.

You solve this problem in two steps:

  1. Create a declarations.d.ts file in the root of the project
  2. Add a reference into the tsconfig file to use the declarations file

declarations.d.ts

// We need to tell TypeScript that when we write "import styles from './styles.scss' we mean to load a module (to look for a './styles.scss.d.ts').
   declare module "*.scss" {
   const content: { [className: string]: string };
   export = content;
}

tsconfig.json

//add the following
"include": [
    "src/**/*.ts", 
    "declarations.d.ts"
  ],

and that’s all 🙂

Reducing SharePoint Framework Code Smells: 3 – Setting up Sonar Scanner and connecting to SonarQube

This is a series on how to set up SonarQube as a Quality Gate in your SharePoint Framework development process. The end goal is to add SonarQube to your build and release process through DevOps. These articles will explain:

  1. How to set up a sample SonarQube server in Azure
  2. Setting up a unit test sample locally
  3. Setting up Sonar Scanner and connecting to SonarQube
  4. How to run a sonar-scanner review manually
  5. How to integrate the code review into your Azure DevOps build and release process.

Introduction

In the previous article we saw how to clone and load up the PnP react-jest-testing sample and run an initial test. I am not going to go into the advantages of unit testing your code – but if you want more information on how and why check out these excellent MVPs and their blog posts on the subject.

In this article we are going to set up Sonar Scanner to analyze the code locally and then connect it to our SonarQube server.

Setting up Sonar Scanner

Sonar Scanner can be downloaded and installed from here. You have to extract it and add the bin directory path to your environmental variable (way easier in Windows 10) to get it to work.

Once that is up and running there are a number of steps which we have to go through to turn our npm test into something which will create reportable files for SonarQube. The process of testing is the same, the only difference is the output and how it is handled.

Setting up a SonarQube Project Key

Within our SonaarQube server create a new project – in this case I called it IceCreamShop for the sake of simplicity

From that I get a the ability to generate a project key

and from there we can continue and get instructions on how to run the sonar scanner for this project.

The information at the bottom is the important part for us:

  • sonar-scanner.bat -D”sonar.projectKey=IceCreamShop” -D”sonar.sources=.” -D”sonar.host.url=http://xominosonarqube.azurewebsites.net” -D”sonar.login=dba68d82c931efe82e8692c9a25bc7c31736b286″

Put another way this is running the CLI for sonar-scanner and passing variables which are not directly configured in the sonar scanner properties config file (which we will come to later)

  • sonar-scanner.bat
    -D”sonar.projectKey=IceCreamShop” #projectKey
    -D”sonar.sources=.” #run the scan from the root directory
    -D”sonar.host.url=http://xominosonarqube.azurewebsites.net” #SonarQube server for the results to be posted to
    -D”sonar.login=dba68d82c931efe82e8692c9a25bc7c31736b286″ #the project key to associate the scan with

So let’s go ahead and run that in our project and see what happens…….

— NOTE —

On a windows machine you must run visual studio code as adminstrator – otherwise it may not be able to create and delete folders as part of the test running process.

If you see an error around – INFO: Sensor SonarCSS Rules [cssfamily] – you must have the sonarJS plugin 5.2.1 installed.

The result is not pretty – for many reasons but let’s look at what we have for now, for this article. As you can see from the output below there are a number of errors and issues reported.

If we look at our SonarQube server though we can see an analyzed project.

 

Looks like we have some smelly code, some bugs and some code debt – this is a really nice feature of SonarQube and why it is helpful in Code Quality reviews. We dont have any code coverage though which is odd……..

As we will come to see in the next article. The code is not all that smelly, it is actually our configuration. 🙂

 

 

 

 

Reducing SharePoint Framework Code Smells: 1 – Setting up SonarQube in Azure

This is a three part series on how to set up SonarQube as a Quality Gate in your SharePoint Framework development process. The end goal is to add SonarQube to your build and release process through DevOps. These three articles will explain:

  1. How to set up a sample SonarQube server in Azure
  2. How to run a code review manually
  3. How to integrate the code review into your Azure DevOps build and release process.

As part of a quality development process not only should developers be linting their code, running unit test and so forth, another step in the process which can be added is a “Code Quality” check using the open source project SonarQube.

In this article we will see how to create a stand alone sample SonarQube server in Azure (and locally if you really want as well).

Introduction

“SonarQube provides the capability to not only show health of an application but also to highlight issues newly introduced. With a Quality Gate in place, you can fix the leak and therefore improve code quality systematically.” 

In practice what it means is an additional tool which developers can use to write better, more maintainable code. This increases quality and reduces overall maintenace costs when implemented as part of a continuous build and deploy process.

There are plugins for JavaScript and TypeScript and thus makes this very applicable to SharePoint Framework development.

Setting up the server

The first step is to create a SonarQube server upon which your code can be reviewed. Some VERY nice person by the name of vanderby has created an ARM template to “Deploy Sonar Cube to Azure“. It is limited by using an embedded database, but it will at least show you the basics before you are ready to scale this properly.

As the github page states – it does take a while to get started but once it is up you can start to use it.

To log into the server I used admin/admin. As this is a sample setup it doesn’t really matter.

Creating a project

Once you are set up and running you can create a project and a key which can then be used to access the server from a command line interface (CLI).

Under the administration server create a new project and once that is complete generate a key for your project

Using these credentals we can test out code from the command line.

Conclusion

Setting up a sample SonarQube server in Azure is pretty simple. As it states though this will not scale and if you are going to use this in an enterprise it will need some better set up. But for the sake of demonstration, it’s just fine.

In the next article we will look at how to apply this to an Azure DevOps build and deploy process for SPFx.

 

Note

You can just as easily set up your own local SonarQube server by following the 2 minute set up installation instructions

Get Started in 2 minutes

 

Securing your AzureDevOps SharePoint tenant credentials with an Azure key Vault.

If you are following an automated Build and Release process for your SharePoint Framework then you will have come across the need to store your tenant SharePoint admin username and password as variables in the pipeline.

Whle this works and I believe the credentials are encrypted, this is not going to fly with enterprise corporate security. They are going to insist that the credentials are kept centrally in a secure KeyVault. Conveniently for us, a KeyVault is available for us to use in Azure.

Using the process described by the Azure DevOps Labs team you can set up a KeyVault and integrate it into your pipeline.

I am adding the KeyVault pipeline into an older version of an SPFx release (for the most up to date doc check this post out).

Once that is run the new password is successfully utilized instead of the variable I had stored within Azure DevOps.

 

Fixing SPFx node-sass binding error on ADO release pipeline

When trying to run the gulp upload-to-sharepoint  encountered the following issue when creating a release pipeline for an SPFx web-part. There was a problem with no binding available for node-sass

[command]C:\NPM\Modules\gulp.cmd upload-to-sharepoint –gulpfile D:\a\r1\a\build\release\gulpfile.js –ship –username *** –password *** –tenant mckinseyandcompany –cdnsite sites/apps/ –cdnlib ClientSideAssets
2019-06-12T14:51:53.5954467Z [14:51:53] Working directory changed to D:\a\r1\a\build\release
2019-06-12T14:51:54.5490645Z D:\a\r1\a\build\release\node_modules\node-sass\lib\binding.js:15
2019-06-12T14:51:54.5497252Z throw new Error(errors.missingBinary());
2019-06-12T14:51:54.5498022Z ^
2019-06-12T14:51:54.5498662Z
2019-06-12T14:51:54.5499258Z Error: Missing binding D:\a\r1\a\build\release\node_modules\node-sass\vendor\win32-x64-48\binding.node
2019-06-12T14:51:54.5499538Z Node Sass could not find a binding for your current environment: Windows 64-bit with Node.js 6.x
2019-06-12T14:51:54.5499731Z
2019-06-12T14:51:54.5499883Z Found bindings for the following environments:
2019-06-12T14:51:54.5500034Z – Windows 64-bit with Node.js 8.x

and the error was actually staring us in the face – “binding available for Node 8″……..

The solution, just like for the build process, you have to add an agent task to ensure the correct version of node is used for the release process.

Using npm ci as part of the SPFx CI CD process through Azure Dev Ops

During the Automated Build and Deploy process for a SharePoint Framework Web Part (as documented here) one of the steps you go through to install the application on the build server is a familiar step ‘npm install’.

This works just fine when working locally and should be, but it is inefficient as part of an automated build process.

For a good explaination of why, check out this stackoverflow answer https://stackoverflow.com/questions/52499617/what-is-the-difference-between-npm-install-and-npm-ci/53325242#53325242

npm install reads package.json to create a list of dependencies and uses package-lock.json to inform which versions of these dependencies to install. If a dependency is not in package-lock.json it will be added by npm install.

npm ci (named after Continuous Integration) installs dependencies directly from package-lock.json and uses package.json only to validate that there are no mismatched versions. If any dependencies are missing or have incompatible versions, it will throw an error.

In my experience this can speed up the build process by more than 50% and as the npm install is the rate determining step for the overall buil, this is very helpful.

The step in the process for the build should look like this:

I have submitted a pull request to update the documentation and we will see if it is worthy 🙂