Testing for editor

[nimishagarwal76]

Hey! I am Nimish Agrawal, this summer I intend to work on writing tests for p5.js-web-editor in this year's Google Summer of Code. Since there does not exist tests currently in the editor I wanted to discuss regarding the structure of the tests and type of testing required. I did some research and at the moment I came up with the following

Client Testing

Some of the work for client testing has been inspired from the tests written for Navbar component. I plan to use shallow rendering of the components. It is useful to constrain testing a component as a unit, and to ensure that tests aren't indirectly asserting on behavior of child components.

I did some research regarding testing for redux connected components. I found that testing them without store is better and we can just test the functionality of our component without passing the store .

Each react Component can be tested for the following:-

React Snapshot Testing

Snapshot Testing is a useful testing tool in case we want to be sure that the user interface hasn’t changed. It doesn't check about the functionality of a component. Components that have fixed UI can have snapshot testing. Snapshots testing is just testing without worrying about logic.
For example for a file node component snapshot testing would look like-

it('renders correctly', () => {
    const tree = renderer
        .create(<FileNode {...props} />)
        .toJSON();
    expect(tree).toMatchSnapshot();
});

Testing Props

Behaviour of components can be tested upon changing of certain props. For eg. in fileNode if isSelectedFile is true then appropriate class should be given.

  it('it renders file node selected', () => {
    const getWrapper = () => shallow(<FileNode {...props} isSelectedFile />);
    const filenode = getWrapper();
    expect(filenode.exists('.sidebar__file-item--selected')).toEqual(true);
  });

Event testing

How will UI respond when certain event occurs. For eg. file should get selected when fileNode is clicked.

  it('check selection of file on click', () => {
    const getWrapper = () => shallow(<FileNode {...props} isSelectedFile />);
    const fileNode = getWrapper();
    const nameButton = fileNode.find('.sidebar__file-item-name');
    nameButton.simulate('click', { stopPropagation() {} });
    expect(fileNode.exists('.sidebar__file-item--selected')).toEqual(true);
  });

Testing Reducers

React reducers can be tested using jest. I plan to write tests for all the reducers. To check the assignment of initialState and then functioning of the reducers.

describe('ide reducer', () => {
  it('should return the initial state', () => {
    expect(ide(undefined, {})).toEqual(initialState);
  });

  it('should handle START_SKETCH', () => {
    const startSketch = {
      type: actions.START_SKETCH
    };
    expect(ide({}, startSketch)).toEqual({ isPlaying: true });
  });

Testing State

How does the state of a component responds upon calling of an event.

Server Testing

I plan to write tests for the controller functions. I am not sure how this can be done. One of the possible way is to maintain a test database. Seed it at start of each test and drop it after the test. It will result in each test having same data to test with and test outcome can be determined.

---

I need reviews and suggestions on the above, along with maybe new tests which can be implemented?
Thanks for your time!

[catarak]

this is awesome! i like that you have laid out the different types of tests. i honestly don't have any experience using these testing frameworks, so i'll have to take a deeper look at this.

[anku255]

@catarak @nimishagarwal76 I intend to write tests for p5.js web editor this summer under GSoC as well.

I have some previous experience and did some research as well and based on that I would like to point out that using shallow rendering to test react components is not the best way to test it.

In this article, Kent C. Dodds explains how shallow rendering doesn't test the real world use case.

However, testing the components by mounting them to the dom may not be easy but we should definitely try to do that first as it resembles the actual scenario.

Also, I would highly recommend to check out react-testing-library by Kent C Dodds. It is very very popular and quite easy to work with.

[andrewn]

👋 @nimishagarwal76, @anku255

I'm going to be working on the web editor for the next few months and I've also been thinking about how to add tests around any new features or bug fixes so this is great timing!

Below are some thoughts I've had about testing the editor...

Server testing / mongodb

I think it's extremely important whatever library we use works with the server code as there's a lot of business logic and data storage that exists in that layer.

Mocking model objects

I'm writing some tests right now for the UserController and finding that the version of Jest we're using has a bug that throws an error when mongoose to be mocked. Mongoose recommend using mocha and this would align us with p5.js so perhaps that's an option?

The issue has been fixed in Jest 24, but trying to upgrade throws errors. I think we also need to upgrade to babel v7.

Testing against real mongodb

Maybe it's more realistic to test against an instance of mongodb and tear it down after every test run? I guess this would slow the tests down though?

React component testing

I'd add my vote react-testing-library over enzyme. I've found that it guides you towards writing tests that focus on how the user experiences and interacts with the application.

In my experience with Jest, mounting components into jsdom works really well and is quite easy.

Redux action creators

Did you have any ideas for how we might test the action creators? A lot of them return functions (signUpUser action example) so that the redux-thunk middleware can dispatch multiple asynchronous actions. Having a approach for that would be 💯 .

Snapshot testing

I haven't used snapshots a lot but I struggle to see the value in them over the other types of tests that @nimishagarwal76 mentions above. My concern is that the JSON they generate that doesn't really let you understand what's changed. I share the concerns in this article about snapshot testing.

Looking forward to hearing your thoughts!