I recently had the opportunity to experiment with an automated testing framework called TestCafe. TestCafe is an open source framework based on node.js. Information on the framework can be found here. It is relatively simple to install, as it only requires an npm install command run from a command prompt.
Once TestCafe has been installed you are ready to start writing your tests. Files for this framework consist of page model files and the actual test files. In the page model files you are defining the different elements that you want to interact with on a particular page. You do this by creating a class that contains the different page elements in the constructor. You also need to make sure that you import the selector class from TestCafe. An example page model can be found below:
In the code above, you see a couple of different ways that I was able to define elements that were contained in the page DOM (document object model). When an item has an associated id you can reference that id with the # symbol (#Account_Name for example). When an object does not have an id assigned to it you can you other attributes to define that item. You can see this done with items like the this.editLink or this.save above. For more information on the different ways that items can be defined in the page model please refer to the documentation available from TestCafe.
Once our page models have been defined we can move on to writing the actual test. The test files for TestCafe are broken into a couple of different parts. The first thing we need to do is import any files that we will need for writing our test. Here is an example of the imports for one of the tests I recently wrote:
The first files I am importing are the page model files for the pages associated with this text (Login Page, Navigation Page, and Account page). The Client Function file is imported in order to allow for URL validation at the end of the test.
The next part of the test file is the fixture portion of the test file. It is here that we provide the starting page for the test, as well as define constants for the classes included in the files that we’ve imported for the page models. Here is a sample of a fixture portion of a test file:
The last line here is something that I really liked about TestCafe, you can include other node.js packages in your tests which allow you to extend what the framework can do. The package that is included in the snippet above (mssql) allow the test to connect to a database and execute queries. I added this functionality to my test ensure that data created during the test was removed at the end of the test, returning the database to the state it was in prior to the test being run.
With that, we’re on to the test portion of the file. The test section of the file is broken down into three main sections. There is a before section, the actual test, and the after section. The before section of the test allows you to perform steps not directly related to the test in question. In my recent tests, I had the steps for logging into the site in the before section of the test. It is important to note here that the before and after sections are completely optional. Here is a sample before section from one of my tests:
Once the before section of the test has been executed, we move on to the main part of the file, that executes the actual test. In this sample test, I am testing a screen that creates customer accounts. Once the account has been created, I verify that I have been taken to the screen that lists all customer accounts which tells me the test has completed successfully. Here is the main test section:
Once the main test section has completed, we wrap up with the after section. In this section, I connect to the database and delete the test account that was created in the main test section. Here is the after section of my test:
With that, this tour of TestCafe comes to a close. I found this framework pretty easy to use, and with the ability to include other node.js packages this has the potential to be a very robust testing solution. I also found that the tests ran much more predictably than those written in Selenium, and I did not observe any of the occasional flakiness I have seen with Selenium based tests. I definitely plan to use this framework more in the future.