GSOC 2019: Idea Selection(p5.js-web-editor)

#1

Hi everyone,

I am Nimish Agrawal, a computer science sophomore from NIT Trichy. I would love to work with The Processing Foundation in this year’s GSOC. I would like to work towards development of p5.js web editor.
I have worked extensively with Node JS (express), Mongoose odm and React. I have knowledge of Redux. You can find me on Github. Here are some of the ideas which caught my attention:

  • Add ability to make sketches private
  • Adding Test Coverage

I am familiar with the codebase and I feel that implementing private sketches is fairly a small project
so I was planning to include Test Coverage also in my proposal or should I send it as another proposal. I wanted to know the views of community regarding this .

Looking forward to work with you all :blush:.

#2

Hi Nimish! It is really up to you what you want to work on, and what you think you could accomplish over the summer. There are also open issues to choose from as well!

#3

I was planning to write tests for the editor. 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?
Code can be viewed here.
Thanks for your time!

#4

@cassie, I am posting initial draft of the proposal here. Please review it and help me improve more on the same.

Proposal Link : https://docs.google.com/document/d/1QnzpeY_WSOHLgi7S34eRj3Hk1CV55iSN_WHSgiV2xIc/edit?usp=sharing

Thanks a lot !!

#5

i think you might be taking on too much work—leave some time for unexpected stuff to come up!

#6

Thanks @cassie for reviewing it.
In that case I decided to make Server Side Testing as an optional part which would be completed only if time permits. This gives me time for completing unexpected stuff.
Rest of the stuff I think I would be able to complete as I can spend atleast 40 hours a week during the summer. Considering the time it took for writing basic tests for FileNode I think I will be able to finish the work as proposed.