Hi! I was passing by and felt that the way we are trying to test this component is a bit counter-intuitive: we are trying to set the sizes of the elements via JS, which is not the way the component would be used! Most probably, the user would have a pre-defined markup for the item slot, which will be passed to it, and the size of the item would be determined by it's styling! So shouldn't our tests also try to mimic the same?

Something like following perhaps?

import { mount } from '@vue/test-utils';
import KListWithOverflow from '../KListWithOverflow.vue';

// Constants for styling
const LIST_STYLES = `
  .list-item {
    display: inline-block;
    white-space: nowrap;
  }
  .list-item.fits {
    width: 80px;
    height: 20px;
  }
  .list-item.overflows {
    width: 25px;
    height: 20px;
  }
  .list-item.medium {
    width: 60px;
    height: 20px;
  }
  .list-item.small {
    width: 20px;
    height: 20px;
  }
`;

describe('KListWithOverflow.vue', () => {
  // Add styles to document before tests
  // TODO: Check if it actually works with Enzyme
  beforeAll(() => {
    const styleElement = document.createElement('style');
    styleElement.textContent = LIST_STYLES;
    document.head.appendChild(styleElement);
  });

  it('renders all items when they fit within available space', async () => {
    const items = ['Item 1'];

    const wrapper = mount(KListWithOverflow, {
      propsData: { items },
      slots: {
        // Can now just use the class on the list item to control its size
        // The class clearly indicates the size of the item and the intent of the test
        item: '<div class="list-item fits">{{ item }}</div>',
        more: '<button class="more-button">More</button>',
      },
    });

    await wrapper.vm.$nextTick();

    expect(wrapper.vm.overflowItems).toEqual([]);
    expect(wrapper.vm.isMoreButtonVisible).toBe(false);
    
    const listItem = wrapper.find('.list-item');
    expect(listItem.element).toHaveStyle({ 
      visibility: 'visible',
      position: 'unset'
    });
  });

  // Can easily write more tests by switching the class of the list item
});

This is just a brief idea, and I have never actually ran this code to ensure it works! but we probably should spend some time But seeing this PR, I thought that it might be worthwhile to look at this alternative approach. I would like to advocate for it as it does not make use of JS to control the sizing of the elements, and thus helps us to get rid of many "magic constants" that appear throughout the tests, or of having to manage the rendering ourselves from inside the tests.

What do you think about this @AlexVelezLl @you-think-you-know-me?

Hey @EshaanAgg, thanks for jumping in. Yes! This is a very good alternative too, although Im not a big fan of having to scroll up to the definition of LIST_STYLES and look for the specific width of a given item to understand the test, in that regard, i feel that having something like setElementSize express better the intention of the test by explicitly declaring the inputs and outputs within the same test case, and it makes it looks a bit more easy to read.

A cons of overwiting the getBoundingClientRect of the element is that if in the future we change this method to get the sizes, we will need to update this method too, although we will just only need to update it inside the setElementSize method as it is well encapsulated, but its nice to have some alternatives.

I think we could implement something more complicated like defining unique classes dynamically in each test case and assigning them to the items inside a setElementSize method (or override the classes, although that could easily break the independency of the tests and one could affect the following ones), if this sounds good, @you-think-you-know-me can give it a try, but if we are spending too much time on it, we I think we can move forward with overriding the getBoundingClientRect method, at least for now, as the intention right now if making sure that the inner logic of setOverflowItems is working well. To have a better accuracy of the actual DOM rendering we can always use visual tests to complement these unit tests, although if in the future we found a better way to set these sizes, we can just change the setElementStyle method, and all the tests should keep working fine :).

Thanks, @AlexVelezLl, for the detailed response. Even I do agree that having to scroll to the top of the document breaks the encapsulation of the test logic in the test itself approach and thus might be a bit counterintuitive. We can definitely ideate better ways to do the same later. Meanwhile, we will currently keep the main aim of this PR to introduce a test suite that covers all the edge cases! Thank a lot again :)