DEV Community: marques woodson

Using the 'after' hook in TestCafe to Cleanup Data

marques woodson — Sat, 15 Feb 2020 15:47:05 +0000

Here's a quick tutorial on how to use the after hook on a TestCafe test.

You'll want to use this hook if your test is creating test data in your environment and you don't want to keep that data around. For example, that test user that you've just created while testing registration or that test product that you just added to your cart or that fake comment you left on a blog post, all of these could be deleted after the test is finished.

Take a look at this test:

import { Selector } from 'testcafe';

fixture('Creating Blog Posts').page('/posts/newPost');

test('should be able to create a new blog post', async (t: TestController) => {
  await BlogModel.addPost('This is a Test Post');
  await t.click(Selector('.submit-button'));
});

We're first going to add a new blog post named 'This is a Test Post'. In this fictional app the user is redirected to the page /posts which lists all available posts. We'll want to click our test post link to make sure this new post is viewable:

import { Selector } from 'testcafe';

fixture('Creating Blog Posts').page('/posts/newPost');

test('should be able to create a new blog post', async (t: TestController) => {
  await BlogModel.addPost('This is a Test Post', `Here's some post content`);
  await t.click(Selector('.submit-button'));
  await t.click(Selector('.post').withText('This is a Test Post'));

  await t.expect(Selector('h1.postName').withText('This is a Test Post').exists).ok()
});

Let's assume each post can be viewed at a URL like /post/id-of-post.

We've added the post, opened the post and verified that a user can see it. Everything's passing 😀. Now what I want to do is delete this post.

This part might be a little tricky. You could choose to use the UI to delete the post. This could work if, for example, you have a "Delete Post" button in the UI on all posts that your user created. Let's imagine that we don't have that option. What we do have is a rest API for working with posts (adding, updating, and deleting). The UI uses this API for adding a post, and we can use the API for removing posts too. All I need is the post's ID.

Each post has the ID in the URL. To grab it we'll use the ClientFunction method that is provided by TestCafe. This method allows us to interact with the browser from inside a test. That means we have access to the window object, which in turn means we can grab the window.location.

import { ClientFunction, Selector } from 'testcafe';

const getWindowLocation = ClientFunctio(() => window.location);

fixture('Creating Blog Posts').page('/posts/newPost');

test('should be able to create a new blog post', async (t: TestController) => {
  await BlogModel.addPost('This is a Test Post', `Here's some post content`);
  await t.click(Selector('.submit-button'));
  await t.click(Selector('.post').withText('This is a Test Post'));

  await t.expect(Selector('h1.postName').withText('This is a Test Post').exists).ok()

  const location = await getWindowLocation();
});

To get the post's ID from the URL we can split the pathname and grab everything after /post/:

import { ClientFunction, Selector } from 'testcafe';

const getWindowLocation = ClientFunction(() => window.location);

fixture('Creating Blog Posts').page('/posts/newPost');

test('should be able to create a new blog post', async (t: TestController) => {
  await BlogModel.addPost('This is a Test Post', `Here's some post content`);
  await t.click(Selector('.submit-button'));
  await t.click(Selector('.post').withText('This is a Test Post'));

  await t.expect(Selector('h1.postName').withText('This is a Test Post').exists).ok()

  const location = await getWindowLocation();
  t.ctx.postId = location.pathname.split('/post/')[0];
});

We assign the value to t.ctx.postId because we want to use that value in an after hook.

ctx is available on the TestController and used to share data between test code and hooks.

Now we can add an after hook to delete that post:

import { ClientFunction, Selector } from 'testcafe';

const getWindowLocation = ClientFunction(() => window.location);

fixture('Creating Blog Posts').page('/posts/newPost');

test('should be able to create a new blog post', async (t: TestController) => {
  await BlogModel.addPost('This is a Test Post', `Here's some post content`);
  await t.click(Selector('.submit-button'));
  await t.click(Selector('.post').withText('This is a Test Post'));

  await t.expect(Selector('h1.postName').withText('This is a Test Post').exists).ok()

  const location = await getWindowLocation();
  t.ctx.postId = location.pathname.split('/post/')[0];
}).after(async (t: TestController) => {
  // assume blogService handles API calls
  await blogService.deletePost(t.ctx.postId);
});

Now that we are using the after hook, we're able to remove the test post. Our environment won't fill up with tons of posts!

Hopefully, this helps you out if you're running automated tests with TestCafe.

Check out my other TestCafe posts here on dev.to, and if you want to reeaaalllly get into TestCafe, watch my course on Pluralsight.

Follow me on twitter 😀

You gotta try the react-redux hooks!!

marques woodson — Sat, 08 Feb 2020 15:00:22 +0000

Readers, if you're using Redux in a React project, you have to try these react-redux hooks. You will love them!

Look at the old way:

const UserComponent = (props) => {
  return (
    <div>
      {props.profile.name}
    </div>
  )
}

function mapStateToProps(state) {
  return {
    profile: state.userReducer.profile,
    auth: state.authReducer.auth
  }
}

export default connect(mapStateToProps)(UserComponent);

And the hooks way:

import { useSelector } from 'react-redux';

const UserComponent = (props) => {
  const profile = useSelector(state => state.userReducer.profile);
  const auth = useSelector(state => state.authReducer.auth);

  return (
    <div>
      {props.profile.name}
    </div>
  )
}

export default UserComponent;

The same goes for dispatching an action.

Before hooks:

const UserComponent = (props) => {
  const login = () => {
    props.login();
  }

  return (
    <div>
      {props.profile.name}
    </div>
  )
}

function mapStateToProps(state) {
  return {
    profile: state.userReducer.profile,
    auth: state.authReducer.auth
  }
}

function mapDispatchToProps(dispatch) {
  return {
    login: () => dispatch(userActions.login),
    logout: () => dispatch(userActions.logout),
  }
}
export default connect(mapStateToProps, mapDispatchToProps)(UserComponent);

After:

import { useSelector, useDispatch } from 'react-redux';
import userActions from './actions';

const UserComponent = (props) => {
  const profile = useSelector(state => state.userReducer.profile);
  const auth = useSelector(state => state.authReducer.auth);
  const dispatch = useDispatch();

  const login = () => {
    dispatch(userActions.login);
  }

  return (
    <div>
      {props.profile.name}
    </div>
  )
}

export default UserComponent;

You HAVE to try these hooks! That's all. Enjoy your weekend 😀😀

Write Custom Hooks in React

marques woodson — Sun, 02 Feb 2020 15:41:39 +0000

Hooks are a relatively new way (React v16.8.x and up) to add state and lifecycle to functional components. Before hooks, you needed to use a class to have these same features. However, using classes in Javascript has its own set of issues:

Some new devs might not have an OO background
What's this for again?
private vs public vs static???
More complicated to share functionality
Transpilers will convert classes to regular functions anyways

I've noticed that many developers prefer writing components as functional components as opposed to classes. They would then convert to a class once state was needed. Well, you don't need to do that anymore.

My Most Commonly Used Hooks

The built-in hooks that I use most often are:

useState
useReducer
useEffect

useState

useState is used to create state properties for your component. It's very similar to this.state in a class component.

class TodoComponent extends React.Component {
  state = {
    content: ''
  }
  ...
}
// OR
class TodoComponent extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      content: ''
    }
  }
  ...
}

// and what we like
function TodoComponent() {
  const [content, setContent] = React.useState('');
  ...
}

The variable setContent in the functional component above is the state updater function. It works like this.setState, and updates the content state and rerenders the component.

React.useState always returns an array with two items, the state variable as the first item, and the updater function as the second item. I highly recommend naming the updater function as set<Name of state var>. This will keep things consistent in your project.

useReducer

useReducer is kinda like a more powerful useState. Why use useReducer?

You have a lot of state props on your component
You really like Redux's reducers

If your component has more than one or two state properties, you may prefer to create those props with useReducer over useState. It may be easier for you to manage a single dispatch function that takes a type and payload which will update your components state, than it is to have a bunch of individual state updater functions.

const initialState = {
  name: '',
  address: '',
  city: '',
};

// Just like in Redux
function userReducer(state, action) {
  switch (action.type) {
    case 'SET_NAME':
      return {
        ...state,
        name: action.payload,
      };
    case 'SET_ADDRESS':
      return {
        ...state,
        address: action.payload,
      };
    case 'SET_CITY':
      return {
        ...state,
        city: action.payload,
      };
  }
}

function UserComponent() {
  const [state, dispatch] = React.useReducer(userReducer, initialState);

  return (
    <div>
      <h1>{state.name}</h1>
      ...
    </div>
  );
}

useEffect

useEffect handles rerendering of your component based on state or property updates. It is also what you use to handle side effects, aka fetching data from an API.

function UserComponent() {
  const [userId, setUserId] = React.useState();
  React.useEffect(() => {
    async function fetchToken() {
      try {
        const response = await axios({
          method: 'GET',
          url: `${API_PATH}/user/${userId}`,
          withCredentials: true,
        });
        setToken(get(response, 'data.trustedTicket'));
      } catch (error) {
        console.error(error);
      }
    }

    fetchToken();
  }, [userId]); // Run the useEffect code when `userId` changes

  return (
    ...
  )
}

Custom Hooks

Now that you have more of an understanding on some very common hooks, lets create our own custom hook. First, we need to name the hook.

function useTodos() {}

Please start every hook with the word use. This is for your own good. The React team has an ESLint plugin that is very helpful at keeping us from messing up our hooks.

We provide an ESLint plugin that enforces rules of Hooks to avoid bugs. It assumes that any function starting with ”use” and a capital letter right after it is a Hook.

Now that we have a hook defined, we can add in some state and functionality.

let nextTodoId = 0;
function useTodos(initialTodos = {}) {
  const [todos, setTodos] = React.useState(initialTodos);

  const addTodo = content => {
    const id = ++nextTodoId;
    setTodos({
      ...todos,
      [id]: {
        content,
        completed: false,
        id,
      },
    });
  };
  const toggleTodo = id => {
    setTodos({
      ...todos,
      [id]: {
        content: todos[id].content,
        completed: !todos[id].completed,
        id,
      },
    });
  };
  return [todos, addTodo, toggleTodo];
}

Custom hooks can take parameters just like any other function. Here i'm passing an initialTodos object that will default to an empty object if undefined.

I've add two updater functions addTodo and toggleTodo that both update the todos state property.

I'm returning an array of values, just like the useState and useReducer hooks.

...
  return [todos, addTodo, toggleTodo];

Using the custom hook

You use the custom useTodos hook just like any other hook.

function MyComponent() {
  const [todos, addTodo, toggleTodo] = useTodos();

  return (
    <>
    <AddTodo addTodo={addTodo}>
    <TodoList toggleTodo={toggleTodo} allTodos={todos}>
    </>
  )

}

We're passing the useTodos hook values to the and components. When addTodo is called, for example, will rerender, since we call a state updater function within addTodo. The todos object will have updated, and that means the component needs to rerender.

Well I hope this has been helpful for you if you're getting into hooks. Let me know if you have any questions about the above code. Have fun coding 😊

React Guides on Pluralsight

marques woodson — Mon, 06 Jan 2020 13:24:02 +0000

Here's a roundup of my 2019 React guides I wrote for Pluralsight.

Working with Bootstrap's Modals in React

Fetching Data and Updating State in a React Class

Validating React-Bootstrap Forms with Formik

Fetching Data and Updating State with Hooks

Working with React-bootstrap Buttons

Generators and Iterators Course Published!

marques woodson — Sun, 05 Jan 2020 23:00:49 +0000

Cover Photo by Cedric Letsch on Unsplash

New Year, new Pluralsight course! 🎉Javascript Generators and Iterators has just published on Pluralsight 🎉. In this course, I will teach you about generator functions, iterators, and iterables. Ever wonder why for..of loops work over strings and arrays, but not objects? Have you used Redux-Sagas in your React app and would like to know what the yield keyword was doing in your code and how it relates to generators? Check out my course to learn all about it.

Generator Functions

Custom Iterators

Mocking and Syntax - Comparing Cypress and TestCafe

marques woodson — Sun, 21 Jul 2019 22:34:48 +0000

Writing end-to-end tests has gotten a lot easier to do with tools like Cypress and TestCafe. These two libraries are very similar. They both allow you to mock HTTP requests, although in slightly different ways. They both have a promise-based API, although Cypress has it's own "promise" in place.

I wanted to put together an article showing you what it looks like in both frameworks to mock an HTTP request and explain why you may want to use this practice. I also wanted to show you why you can't use async/await for Cypress tests.

Writing Tests: TestCafe vs Cypress

Let's compare what writing a test looks like in Cypress and TestCafe. For some context, imagine we have a UI that consists of a list of products, with a text input used for filtering down the list. When a user types into the input, the list of products should immediately update to filter out products that don't match the user input.

In TestCafe, this test could look like this:

test('should properly filter products based on the query entered', async t => {
  // Get the count of products on initial page load
  const originalProductCount = await Selector(`[data-locator='individual-product']`).count;

  // Type a string into the filter input, to filter out products that don't match
  await t.typeText(Selector(`[data-locator='filter-input']`), 'Ben');

  // Get the new count of visible products on the page
  const countOfFilteredProducts = await Selector(`[data-locator='individual-product']`).count;
  await t.expect(originalProductCount).notEql(countOfFilteredProducts);
  await t.expect(countOfFilteredProducts).lt(originalProductCount);
  await t.expect(countOfFilteredProducts).eql(2);
});

This same test in Cypress would look like this:

it('should properly filter products based on the query entered', () => {
  // Get the count of products on initial page load
  cy.get('[data-locator=individual-product]').then(products => {
    let originalProductsCount = products.length;

    // Type a string into the filter input, to filter out products that don't match
    cy.get(`[data-locator='filter-input']`).type('Ben');

    // Get the new count of visible products on the page
    cy.get('[data-locator=individual-product]').then(filteredProducts => {
      let filteredProductsCount = filteredProducts.length;
      expect(originalProductsCount).not.to.equal(filteredProductsCount);
    });
  });
});

Promises in Cypress

You may have noticed that I'm not using async/await with the Cypress tests. Unfortunately, that is a trade-off when using Cypress. The cy commands do not return actual promises, even though you can use .then(...) on each command. The "promise" that is returned is a Chainer object, which is a wrapper of a real promise. They chose this design to make Cypress much more deterministic and stable, as normal JS promises have no concept of retries or retry-ability.

From the docs:

The Cypress API is not an exact 1:1 implementation of Promises. They have Promise like qualities and yet there are important differences you should be aware of.

You cannot race or run multiple commands at the same time (in parallel).

You cannot ‘accidentally’ forget to return or chain a command.

You cannot add a .catch error handler to a failed command.

The downside is I can't do something like:

// async / await will not work
it('does something cool', async () => {
  // `cy` commands will never return a useful value
  const value = await cy.get('.product-list');
  expect(value.length).to.equal.(10);
})

Instead, your code would look closer to this:

it('should have only 10 products', () => {
  cy.get('.product-list')
    .then(products => {
      expect(products.length).to.equal.(10);
    });
})

This should be very familiar since before async/await all of our promises were written this way.

Mocking HTTP Requests

Both TestCafe and Cypress provide a way to mock HTTP requests in your test. This can speed up your test runs since you won't have to wait for real server responses, which can sometimes take a while, depending on what your app is doing. You should still have a few tests that depend on actual server responses, like for testing login flow. But when testing more granular functionality you should mock some of your requests. I know it sounds weird to do that, but I think of it as I'm testing the UI right now, not the API. You most likely already have tests in place for your API and you don't need to test it twice. You may ask "But what if the API model changed? Won't my test fail now?". If the API changes, that most likely means your UI that handles the responses/requests would need to change as well, which means you probably need to update your tests anyways.

If mocking your HTTP requests still has you worried, you don't HAVE to do it. It's totally up to you and your team to decide what will bring you the most confidence in your tests.

Mocking in TestCafe

To mock HTTP requests in TestCafe, you would use the RequestMock constructor.

// api-mocks.ts
import { RequestMock } from 'testcafe';
const mock = RequestMock()
  .onRequestTo('https://some.domain.com/api/products')
  .respond({ data: 'data from API' }, 200); // returns JSON response { data }, and 200 statusCode

export default mock;

Then import the mock into your test and use the fixture or test hook called requestHooks:

// spec.ts
import { Selector } from 'testcafe';
import mock from './api-mocks';

fixture('A fixture')
  .page(...)
  .requestHooks(mock)

You can also chain multiple requests and responses to the mock:

// api-mocks.ts
import { RequestMock } from 'testcafe';
const mock = RequestMock()
  .onRequestTo('https://some.domain.com/api/products')
  .respond({ data: 'data from API' }, 200)
  .onRequestTo('https://some.domain.com/api/users')
  .respond(null, 204) // returns empty response
  .onRequestTo('https://some.domain.com/api/products/123')
  .respond((req, res) => {
    // returns a custom response
    res.statusCode = '200';
    res.setBody({ data: { name: 'product name', id: 123 } });
  });

export default mock;

Mocking in Cypress

Stubbing responses in Cypress is slightly different. To tell your tests to start stubbing specified requests, first, you need to call cy.server() to enable it. To tell the server what requests to stub and what response to return you then call cy.route(<options>).

cy.server();
cy.route({
  method: 'GET',
  url: '/products',
  response: [{ id: 1 }, { id: 2 }], // list of mock products.
});

You could also skip the route object and use parameters instead:

cy.server();
cy.route('GET', '/products', [{ id: 1 }, { id: 2 }]);

Cypress has this idea of fixtures. Unlike TestCafe, Cypress fixtures are JSON objects that hold the data you'd like to use in a mocked response. This is very useful since sometimes an API can return complex data, and having that in a separate file keeps your spec file clean. So instead of specifying a response inline within the cy.route method, you can specify a fixture to be used. All you need to do is create a new .json file within the /cypress/fixtures/ directory.

// cypress/fixtures/products.json
[
  {
    id: 1,
    name: 'Product A',
  },
  {
    id: 2,
    name: 'Product B',
  },
];

// spec.js
it('Should display a list of products', () => {
  cy.server();
  cy.route('GET', '/api/products', 'fixture:products.json').as('getProducts');

  cy.visit('/a-page-with-a-list-of-products');
  cy.wait(['@getProducts']);

  cy.queryByText('Product A').should('exist');
  cy.queryByText('Product B').should('exist');
});

Conclusion

I hope this helps someone decide between what framework to use for end-to-end testing. I think both of these options here are great choices, and you can’t really go wrong. Mocking your applications HTTP requests can really speed up your test runs. You should still fully test the critical paths, but for the rest of your tests, you should mock. When you are mocking while using Cypress, I recommend utilizing fixtures to define your data. It just keeps things organized.

If you’re just getting started with end-to-end testing check out my course on Pluralsight, End-to-end Web Testing with TestCafe: Getting Started.

Thanks for reading :)
Follow me on twitter 😀

Concurrency and Test Data in TestCafe

marques woodson — Fri, 21 Jun 2019 12:30:17 +0000

TestCafe is great. It makes it super simple to add e2e testing to your repertoire, making you not only the front-end engineer but the QA engineer too. In my time using TestCafe I have run into situations that I think are common to most test suites. Doing something like creating/deleting user data before and after tests while using concurrency can give you some trouble. I'll show you how I've setup a project to handle this situation.

Setup/teardown data while trying to use concurrency.

Running your tests in parallel is important to make sure your test runs are fast. I always have at least 4 running at the same time by using the concurrency option.

$ testcafe -c 4 chrome:headless tests/test.ts

I'd also like to create users before my test is run. My first thought was to use the fixture.before hook to create those users, then use the fixture.after hook to delete them. This would only work however if I used different users for each fixture since if I was running tests in parallel, users could possibly be deleted before another test is finished executing, throwing errors and failing tests.

// test-one.ts
import { addUsers, removeUsers } from './some-custom-module';
...
fixture('Fixture 1').page(...)
 .before(async () => await addUsers();)
 .after(async () => await removeUsers();)

// test-two.ts
import { addOtherUsers, removeOtherUsers } from './some-custom-module';
fixture('Fixture 2').page(...)
 .before(async () => await addOtherUsers();)
 .after(async () => await removeOtherUsers();)

As you can see, each fixture is independent from each other. Running these parallel shouldn't give you an issue and most likely solves the more common use cases for setting up and tearing down data.

But what if you have multiple fixtures that will all use the same users? You would not be able to do what is shown above. Something you could do instead is create and delete users when you create the test cafe runner:

//testcafe-config.js
const userService = require('some-module');

createTestCafe('localhost')
  .then(tc => {
    testcafe = tc;
    // Run code to add users
    userService.addUsers();

    const runner = testcafe.createRunner();
    return runner
      .src('...')
      .browsers('...')
      .run();
  })
  .then(failedCount => {
    console.log('Done: ', failedCount)
    //Tests are done, cleanup those users
    userService.removeUsers();
    testcafe.close();
  })
  .catch(error => {
    //Just in case there's an error
    userService.removeUsers();
  })

Now all fixtures in your suite will have access to the same test data. Remember this means that if you were to do something like modify the user's name in one fixture, but test for that same user's name in another fixture, you could get a failure. If you want to create data in this way, I'd say to only create read-only data that will not change from within a fixture.

If you've come up with other ways to setup and teardown test data, let me know in the comments.

Also if you want to learn more about TestCafe, take a look at my course End-to-end Web Testing with TestCafe: Getting Started on Pluralsight

Thanks and Happy Testing :)

Get $100 Off Pluralsight Premium and Personal Annual Subscriptions

React Specific Selectors in TestCafe

marques woodson — Mon, 27 May 2019 13:08:58 +0000

The TestCafe Selector function allows you to use CSS selectors to find the elements that you need to test in the DOM. Using CSS selectors is extremely convenient, and many other testing libraries use the same approach. When using TestCafe to test a React application, using plain CSS selectors will definitely get the job done, is normally the route I take. But it's not the only option.
TestCafe has React-specific selectors that allow you to traverse a component hierarchy to select components by name, by property value, and even the component's state.

Let's say we have the above component tree. We could use React selectors to get the ProductList component like this:

The ReactSelector function takes in a component name and should start with the root component. The comparable CSS selector for the ProductList variable we have above would be:

Selector('.app > .productList');

ProductList would need to be an immediate child of the App component. This can get annoying since in a more complex React app, there could be many levels of nested components to find. Luckily, TestCafe thought of that:

The findReact function allows you to search for a react component nested inside of another component. It's very similar to the find method on the Selector object.

Selector('#component').find('h1');

withProps({ … })

Selecting components by name is quick and easy. But in a real application having something more exact would be better. You could either use more selectivity in a CSS selector, or you can use ReactSelector's withProps function to find a component with specific props.

withProps will work even if your property value is an object, with matching either being partial or exact.

The more you know about your React components, the easier it'll be to find them in the DOM. You could bypass all CSS selectors if you wanted to.

You would need to be careful with this approach, however. If you are doing exact object matching in your selector, but then decide to add a new prop to the object in your component, you would need to update the end to end test as well. I personally don't like to tie my testing code to my application code as much, since it just makes for something else I need to think about while working on a feature. I'd just recommend being careful not to overdo the exact match, especially on complex objects, to save yourself some headaches.

getReact()

There are some test scenarios where you would like to test that a property was updated correctly, or check the value of state. Ideally, you would use something like react-testing-library to test these types of interactions. If you would rather check the internals in your end to end test though, the getReact function is what you'll need. The getReact function returns a client function that resolves with an object of component properties and state.

With this info you can run expectations against state values or component properties:

I would still recommend a Jest test to make these checks, but sometimes that's not always the easiest solution, especially if you have a lot of complex setup involved. You could use getState in a TestCafe test and run it in chrome headless mode. That may run fast enough to make it feel like a Jest test, depending on your app. Try it out :)

In Conclusion

TestCafe is a wonderful tool for creating end-to-end tests and is really transforming how developers approach testing. There are smart test actions and assertions with automatic waiting for elements to appear, no need for webdriver, and full TypeScript support. Along with React specific selectors, there are other selector libraries for Vue, AngularJS, Angular, and Aurelia. I think there are a lot of benefits to using React Selectors in a React app, and you should give them a try while writing your next test!

The more you know about your React components, the easier it'll be to find them in the DOM. You could bypass all CSS selectors if you wanted to.
You would need to be careful with this approach, however. If you are doing exact object matching in your selector, but then decide to add a new prop to the object in your component, you would need to update the end to end test as well. I personally don't like to tie my testing code to my application code as much, since it just makes for something else I need to think about while working on a feature. I'd just recommend being careful not to overdo the exact match, especially on complex objects.

Follow me on twitter 😀

Better E2E testing with TestCafe

marques woodson — Mon, 27 May 2019 13:03:42 +0000

If you want to learn more about TestCafe, please check out my course End-to-end Web Testing with TestCafe: Getting Started on Pluralsight.

TestCafe is a Node.JS tool for running end-to-end tests in the browser.

Why I like TestCafe

With TestCafe I can write all of my code in Typescript or the latest (ES2017) JS. When I can write my E2E tests in the same manner that I write my application code, I see it as a huge win. I use Typescript in my application code to reduce confusion around what my code is actually doing so that the rest of my team can better understand my code. Using these same principles in E2E testing seems like a no-brainer. Also, IntelliSense :)

One of my favorite parts about being able to use more modern Javascript in my tests is the use of async/await. Since most of the actions that are run during a test return promises, my code looks like this:

// good
test('Should be able to login', async t => {
  await t.typeText(Selector('#username'));
  await t.click(Selector('#login-button'));
  //Or chain the calls
  await t.typeText(Selector('#username')).click(Selector('#login-button'));
});

Instead of using callbacks:

// booo!
test('Should be able to login', t => {
  t.typeText(Selector('#username')).then(() => {
    t.click(Selector('#login-button'));
  });
});

Testcafe's ability to automatically wait for pages to load, XHR requests to finish and elements to appear without me having to set up timeouts makes my life so much easier. I also like the feature of slowing down a test's execution, so that you can easily see what is happening in the browser.

Speed to setup

To get started, all you have to do is install TestCafe with npm:

$ npm install -g testcafe

Node.js is your only dependency. One of my favorite parts is that you DON'T need webdriver installed! You literally just npm install TestCafe and you're ready to go.

Each test starts with a fixture. A fixture is basically a test category, and every test file requires one or more fixtures:

fixture(fixtureName);
// or
fixture`fixtureName`;

Now you can start adding tests:

fixture`Login Functionality`;
test('Should be able to login', async t => {
  await t
    .typeText(Selector('#username'))
    .click(Selector('#login-button'))
    .expect(true)
    .ok(); //This is just an example assertion. Don't do   this in real tests.
});
fixture`Logout functionality`;
test('Should be able to logout', async t => {
  await t
    .click(Selector('#logout-button'))
    .expect(true)
    .ok();
});

Here's a link to the test API that (https://devexpress.github.io/testcafe/documentation/test-api/) shows all of the available testing capabilities.

Page Models

Setting up page models is still the recommended practice in-browser tests. A page model is basically a file that holds references to browser elements (buttons, links, anything that you're testing will be interacting with). I also like to add page interaction methods to the page models as well. Doing so will keep your tests cleaner and smaller.

import { Selector } from 'testcafe';
export default class HomeModel {
  constructor() {
    this.signInLink = Selector('#sign-in');
    this.username = Selector('input[type=“text”]');
    this.password = Selector('.password');
    this.submitButton = Selector('#submit');
    this.forgotPasswordLink = Selector('.forgot-password');
  }
  async loginUser(t: TestController) {
    await t
    .typeText(this.username, 'someUser')
    .typeText(this.password, 'password123')
    .click(this.submitButton);
  }
}
//Or if you prefer Typescript
export default class HomeModel {
  signInLink: Selector;
  forgotPasswordLink: Selector;

  constructor() {
    this.signInLink = Selector('#sign-in');
    this.forgotPasswordLink = Selector('.forgot-password');
  }
}

In our page model above, we define page elements in the constructor using the Selector API from TestCafe. Then we have a loginUser method that interacts with those page elements. This means that in our test, we can just write:

import HomeModel from './home-model';
const Home = new HomeModel();
… //Test fixture code
test('Loggin in', async t => {
  await Home.loginUser(t);
  await t.expect(…).ok();
});

The reason we want this is so that if the application code every changes, you should only need to update your page models and not all of your tests. The Selector API is fairly robust on its own, but if you're using a framework like React, AngularJS, Angular, Vue, or Aurelia, TestCafe has you covered there (https://devexpress.github.io/testcafe/documentation/test-api/selecting-page-elements/framework-specific-selectors.html). There are selector libraries specific to each of those frameworks developed by the community.

You can still run your tests remotely if need be. We use SauceLabs, but I'm sure the other players in that space are just as good.

If you are running browser/e2e tests (and you really should be) then I recommend trying out Testcafe. It's fast to set up and works with the most popular JS frameworks. If you want strongly typed tests, you can use Typescript without any extra Typescript configuration (it's bundled in the TestCafe package).

I hope this post helps out anyone looking at options for E2E testing their application. Feel free to leave a comment if I got anything wrong or if you have any questions. FO Thanks for reading :)

Follow me on twitter 😀

TestCafe: Organizing Tests with Metadata

marques woodson — Mon, 25 Mar 2019 21:54:48 +0000

This is a cross-post from my blog on Medium

The TestCafe framework has a nice little feature for fixture and test organization. All fixtures and tests have an optional meta property that you can use to attach any additional information. Let's look at how we can use this meta property for more granular test runs. We'll first look at a couple of different ways to filter your tests.

Filter by filename

This I think is the most common way of splitting up your tests. You would put your authentication tests in a file like authentication.spec.ts, or profile page tests in profile.spec.ts, etc. What if you want to run a subset of those tests as smoke tests? Or you have a set of tests that you only want to run in Internet Explorer or Safari? If you are relying on file names, you could do something like create a file named smoke-tests.spec.ts, and copy/paste into it any tests you would want for a smoke test run. This requires duplication of testing code though, and can be difficult to maintain.

Filter by fixture or test name

You can filter what tests are run just by the fixture name:

$ testcafe chrome login.spec.ts --fixture "Bad Passwords"
# or by regular expression 
$ testcafe chrome login.spec.ts --fixture-grep "Bad.*"

To tell TestCafe what fixtures/tests will be smoke tests, you could name your fixtures something like:

fixture('Bad Passwords: smoke'); 
test('Incorrect passwords should show an error: smoke');

Then you could filter with:

--fixture-grep "smoke"
# or
--test-grep "smoke"

This could make the fixture names brittle, however. What if a fixture name has the word "smoke" in it, even though you don't want it to be a smoke test?

Filter using metadata

We can use the meta property to create a subset of tests like this:

// login.spec.js 
fixture('Login Page') 
 .page('https://some-app.com') 
 .meta('smokeTest', true) 
 .meta('ieOnly', true); 
// Or you can pass an object instead 
...
 .meta({ smokeTest: true, ieOnly: true})

With the meta property in place, you can now run tests like this:

$ testcafe chrome login.spec.js --fixture-meta smokeTest=true

You can even use the meta property on a test:

// login.spec.js 
fixture('Login Page') 
 .page('https://some-app.com'); 
test('should show an error with incorrect username', …) 
 .meta({ smokeTest: true });

and you can use the --test-meta option just like the --fixture-meta option:

$ testcafe chrome login.spec.js --test-meta smokeTest=true

Now we have a clean way of creating test subsets that don't rely on fixture/test name, or file name. Not only can metadata be used for filtering tests, but that information can be used in your own custom test reports.

Conclusion

TestCafe's metadata feature makes it simple to separate and organize test runs within your end to end suite, not only at a fixture level, but at the test level. I think you should definitely work it into your tests to get the most out of TestCafe.