Dashboard one column mode test

[ranbena]

What type of PR is this?

• Other - Test

Description

[ranbena]

@arikfr any other aspect to test with this feature?

[ranbena]

I'll add some controls hide/show testing

[gabrieldutra]

More tests 🙂.

I left some comments, requesting changes more to the ones with assertions that don't work ^^

[gabrieldutra]

With context how about moving cy.viewport(800, 800); to its beforeEach hook?

You'll have to invert tests order so the assertion for one column mode comes first, but it seems to make sense:

context('viewport width is at 800px', () => {
  beforeEach(function () {
    cy.visit(this.dashboardUrl);
    cy.viewport(800, 800);
  });

  it('shows widgets with full width', () => {
    cy.get('@textboxEl').should(($el) => {
      expect($el.width()).to.eq(785);
    });
    cy.viewport(801, 800);
    cy.get('@textboxEl').should(($el) => {
      expect($el.width()).to.eq(393);
    });
  });
});

[ranbena]

@gabrieldutra I went for this, wdyt?

describe('Viewport width affects presentation', () => {
  context('viewport width is at 800px', () => {
    it('shows widgets with full width' ...
    it('hides edit option' ...
    it('disables edit mode' ...
  });

  context('viewport width is above 800px', () => {
    it('shows widgets with specified width' ...
    it('shows edit option' ...
    it('enables edit mode' ...
  });

  context('viewport width is at 767px', () => {
    it('hides menu button' ...
  });

  context('viewport width is above 767px', () => {
     it('shows menu button' ...
  });
});

[gabrieldutra]

I would say this would be the state-of-the-art when considering tests organization. However, Cypress has a cost associated to each new it block, so it's worth it to check how much will be added after this.

From this point whatever you want is good to me, so LMK when I can check it again 🙂

[ranbena]

I went for sth leaner:

[kravets-levko]

@ranbena Just a note about these tests: does it make any sense to split dashboard_spec.js into smaller files? There are actually two reasons why I think about this:

1. it's already quite large - with all issues that come from that (harder understanding, navigation in code, etc.).
2. I use a VM for development with 8GB RAM, and to run this file from Cypress GUI I have to close everything - IDE, browsers, etc. - because this suite needs all free memory to run successfully (I think it's because of Cypress "time machine", but not sure). I know that 8GB is probably not a lot and I should add some memory to VM, but 1) I cannot do it right now for a some reason; 2) it will not solve the issue in long perspective.

WDYT?

[ranbena]

does it make any sense to split dashboard_spec.js into smaller files?

@kravets-levko yes, now that tests are done (for now 😅) I'll split it into 3 files, in a followup PR.

[gabrieldutra]

I use a VM for development with 8GB RAM... I should add some memory to VM

It's sort of fun to see you say it, because 8GB RAM is all I've got to my laptop now 😆. Eventually I'm gonna upgrade it, but I didn't see a need so far. I'm not sure how you managed to have issues with it, but I can usually run Cypress tests with 4 GB available (the rest already used by Chrome and other apps).

I agree we should split it anyway in a following PR.

[gabrieldutra]

I would say this would be the state-of-the-art when considering tests organization. However, Cypress has a cost associated to each new it block, so it's worth it to check how much will be added after this.

From this point whatever you want is good to me, so LMK when I can check it again 🙂

[gabrieldutra]

Looks nice! ☕