Create a single repo for all the testing solutions related to Styled Components

[MicheleBertoli]

This project forked an older version of jest-styled-components and provides some of the same functionalities with different APIs, which generates confusion for the users.
Why don't we "merge" the projects (under the org I guess) and create a single repo for all the testing solutions related to Styled Components?
We could use Lerna to manage dependencies and packages.
Let me know if you are interested.

[mbasso]

Hi Michele,
yes, I think that this is a good idea, also, the org is the right place to put the repo. I haven't used Lerna before, but I'll start studying it as soon as possible.
I'd like to maintain the same concept under styled-components-test-utils: make the APIs compatible with jest but also with expect and others libraries.
What do you think about that?

[MicheleBertoli]

Sure, the new package (or packages) is going to have all the same features (and potentially more).
The goal is to provide consistent APIs and share the code.
We should agree on the signature of toHaveStyleRule, because I believe the extra params (e.g. options) should be passed to the matcher rather than expect.
Also, we have to find a cool name (something related to 💅, like polished - what about nailed?) and a logo :)

[yanawaro]

Cool 🎉, Testing styled components would be more awesome!

[mbasso]

Sure, the new package (or packages) is going to have all the same features (and potentially more).
The goal is to provide consistent APIs and share the code.

Awesome! Maybe we could solve #1 directly in the new package?

We should agree on the signature of toHaveStyleRule, because I believe the extra params (e.g. options) should be passed to the matcher rather than expect.

I thought a little about it and that makes sense, it is semantically correct to pass options to the matcher. So, we might have a signature like:

expect(tree).toHaveStyleRule(selector, value, { modifier, media })

Also, if we want to test css API, do you think that a signature like this might be ok?

expect(css).toHaveStyleRule(selector, value, { props, media, modifier })

I'm not totally sure about the last one... But I have no other ideas at the moment.

Also, we have to find a cool name (something related to 💅, like polished - what about nailed?) and a logo :)

Yeah, I totally agree with you, it gives the package a kind of personality. nailed is great 😄

P.S.
A small organizational note:
Unfortunately, I'll be on vacation in a few days and I'll not be able to develop without my computer. However I can answer to the this issue to define signatures and so on using the phone. I'll come back home the 10th of august

[MicheleBertoli]

@mbasso enjoy your vacation and let's talk about this when you are back.

@yanawaro it'd be awesome to get you involved in this project.

[yanawaro]

I'm glad to help.

@mbasso I love that right now this repo has many features supported for modifiers, media, pseudos already! I understand that https://github.com/mbasso/styled-components-test-utils already supports using toHaveStyleRule with enzyme's api or not? as seen in https://github.com/mbasso/styled-components-test-utils/blob/master/src/matchers/toHaveStyleRule.js#L23 (but docs says not 😂 ). I've seen you used the component's state.generatedClassName as I did with my own utility before.

I think combining modifier, media as one object should be more easier to add new things.

@MicheleBertoli Right now, If creating enhancements for https://github.com/styled-components/jest-styled-components how would it be aligned in the end?

I'll follow up this topic and see what I can do. 👍

[MicheleBertoli]

@yanawaro I'd try to avoid using Enzyme's internals (e.g. generatedClassName) as much as I can.
For now, I'd just add new features on both packages and then we'll figure out how to merge the libraries providing the best experience to the users.
Thank you very much!

[mbasso]

@yanawaro Thank you! I'm happy that we'll work together on this project 😄
styled-components-test-utils works fine with react-test-renderer, react-test-renderer/shallow and enzyme's shallow.
I've written that enzyme's mount is not supported yet because, for some reasons that I have to understand (probably because I'm using internals, and I agree with the comment of Michele for this reason), tests fail. As you can see here some lines are not covered. So, I'm not sure that I can say otherwise at the moment.

@MicheleBertoli thank you, I'll write to you the 10th of august!

[mbasso]

@MicheleBertoli I'm back, we can talk about the project :)

[MicheleBertoli]

Welcome back @mbasso, I hope you enjoyed your holidays.

[mbasso]

Thank you! Yeah, I really needed them.

What do you think about this?

[MicheleBertoli]

I totally agree with you, @yanawaro recently added the third options parameter as well.
I think that's the way to go.

Next things I'd like to do:

• figure out exactly what's going to be the surface of the package (APIs, supported environments/libs, serializers, matchers, single VS multiple packages, and so on)
• setup a simple boilerplate with Lerna so that we can start coding

Unfortunately, I'm a bit busy until the end of the month because I'm preparing a talk, but let's keep discussing and sharing ideas.

[mbasso]

I'll try to write my thoughts, let me know what do you think

supported environments/libs

At the moment styled-components-test-utils supports jest, expect, chai and jasmine. I'd like to add ava but it seems that it cannot be extended at the moment, the same for tape.
I'd like to render components using react-test-renderer, react-test-renderer/shallow, enzime's shallow and enzyme's mount.
Would you like to add other libraries?

APIs, matchers

Starting from our 2 libs, here is the list of matchers:

// test styled components: https://www.styled-components.com/docs/api#styled
expect(tree: reactElement).toHaveStyleRule(selector: string, value: string | number | RegExp, options?: {
  modifier?: string,
  media?: string | object,
});

// test css api: https://www.styled-components.com/docs/api#css
expect(css).toHaveStyleRule(selector: string, value: string | number | RegExp, options?: {
  modifier?: string,
  media?: string | object,
  props?: object,
});

// test keyframes api: https://www.styled-components.com/docs/api#keyframes
expect(keyframe: string).toHaveKeyframeRule(keyframeSelector: string, selector: string, value: string);

// test injectGlobal api: https://www.styled-components.com/docs/api#injectglobal
expect(style: string).toBeAGlobalStyle();

// snapshot
expect(tree: reactElement).toMatchSnapshot();


// examples

// toHaveStyleRule

const Example = styled.div`
  padding: 2em 1em;
  background: papayawhip;

  &:hover {
    background: palevioletred;
  }

  @media (max-width: 600px) {
    background: tomato;

    &:hover {
      background: yellow;
    }
  }

  > p {
    text-decoration: underline;
  }

  html.test & {
    display: none;
  }
`;
const component = renderer.create(<Example />);
expect(component).toHaveStyleRule('background', 'papayawhip');

// pseudo selectors
expect(component).toHaveStyleRule('background', 'palevioletred', {
  modifier: ':hover', // or '&:hover'
});

// descendant-selectors
expect(component).toHaveStyleRule('text-decoration', 'underline', {
  modifier: '> p',
});

// contextual selectors
expect(component).toHaveStyleRule('display', 'none', {
  modifier: 'html.test &',
});

// media as string
expect(component).toHaveStyleRule('background', 'tomato', {
  media: '(max-width: 600px)',
});

// media as object
// it should be thought of as if it is the current state of a device/browser.
// a type value must be specified, and it can not be "all".
// The returned rule is the one applied under those conditions
expect(component).toHaveStyleRule('background', 'tomato', {
  media: {
    type: 'screen',
    width: '700px',
  },
});
expect(component).toHaveStyleRule('background', 'papayawhip', {
  media: {
    type: 'screen',
    width: '400px',
  },
});


const style = css`
  color: ${props => props.primary ? props.primary : 'white'}
`;
expect(style).toHaveStyleRule('color', 'black', {
  props: {
    primary: 'black',
  },
});


// toHaveKeyframeRule

const fadeIn = keyframes`
  0% {
    opacity: 0;
  }
  100% {
    opacity: 1;
  }
`;
expect(fadeIn).toHaveKeyframeRule('0%', 'opacity', '0');


// toBeAGlobalStyle

injectGlobal`
  input {
    font-family: Roboto;
  }
`;
expect(`
  input {
    font-family: Roboto;
  }
`).toBeAGlobalStyle();


// toMatchSnapshot

const tree = renderer.create(<MyComponent />).toJSON();
expect(tree).toMatchSnapshot();

I have only one problem with theme, I don't know how we can avoid to do this in each test:

const component = <Button theme={theme} />;

single VS multiple packages

I think that a single package might look like this library, users have to do something like:

import 'styled-components-test-utils/jest';
// or, for example, import 'styled-components-test-utils/chai'; 

With multiple packages the repo will be better organized and less confusing for users, they will be able to install directly the right package.
In addition, each package can contain its own installation guide, in this way we can keep the main README clean.
Maybe we might have a structure like this:

nailed
│
└───packages
|   |   nailed-jest
|   |   nailed-expect
|   |   nailed-chai
|   |   nailed-jasmine
│   │   nailed-matchers
│   │   nailed-serializers
|

setup

Will you create the repo (nailed) under the org? Can we also setup and use travis and coveralls? I think that we can use the MIT license and the Contributor Covenant Code of Conduct

[MicheleBertoli]

This is awesome, thanks @mbasso.
It's exactly what I had in mind as a starting point.
Also, my presentation is almost ready and I'll be ready to start working on this soon.
Thank you very much!

[mbasso]

Awesome! Let me know when you are ready 😄

[MicheleBertoli]

I'm so so so sorry but I just realized I don't have the capacity to start a new project anytime soon.
I've got another talk next week, and I barely find the time to keep up with the issues on my repos.
It would have been great to work together and I can see how merging the packages would be beneficial for the community.
I'm going to close this for now but I promise I'll ping you as soon as I'll be ready to start for real.
Thank you very much!