Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 15 14:15

    depfu[bot] on update

    (compare)

  • Apr 15 14:15
    depfu[bot] closed #795
  • Apr 15 14:15
    depfu[bot] commented #795
  • Apr 15 14:15
    depfu[bot] labeled #803
  • Apr 15 14:15
    depfu[bot] opened #803
  • Apr 15 13:10

    depfu[bot] on update

    Update eslint-config-prettier t… (compare)

  • Apr 11 06:25
    depfu[bot] labeled #802
  • Apr 11 06:25
    depfu[bot] opened #802
  • Apr 11 05:21

    depfu[bot] on update

    Update eslint-plugin-promise to… (compare)

  • Apr 06 07:24

    depfu[bot] on update

    (compare)

  • Apr 06 07:24

    papandreou on master

    Update eslint-plugin-markdown t… Merge pull request #801 from un… (compare)

  • Apr 06 07:24
    papandreou closed #801
  • Apr 06 07:00

    depfu[bot] on update

    (compare)

  • Apr 06 07:00
    depfu[bot] closed #793
  • Apr 06 07:00
    depfu[bot] commented #793
  • Apr 06 07:00
    depfu[bot] labeled #801
  • Apr 06 07:00
    depfu[bot] opened #801
  • Apr 06 05:55

    depfu[bot] on update

    Update eslint-plugin-markdown t… (compare)

  • Mar 31 01:51

    depfu[bot] on update

    (compare)

  • Mar 31 01:51
    depfu[bot] closed #799
Miroslav Nikolov
@moubi
Any thoughts on snapshots?
Sune Simonsen
@sunesimonsen
Short answer don’t snapshot structure, it makes for fragile tests. Only assert things the is expected in the given context.
I almost never satisfy a structure, I mostly test for presence of test ids or values of elements with test ids.
Miroslav Nikolov
@moubi
Thanks for the useful input.
Sune Simonsen
@sunesimonsen
@moubi np, I can try to elaborate a bit more at another, I’m a bit busy right now ☺️
Peter Müller
@Munter
I have done a few tests where I do indeed run a satisty assertion on a structure. For a11y component implementations where the aria attributes change on multiple nesting levels in specific states. But it's definitely brittle
Andreas Lind
@papandreou
I like snapshot-based assertions for some things, but overusing them in a code base can lead to snapshot blindness where you just say "whatever" and stage the changes without really looking.
My rule is: Don't snapshot today what you can't be bothered to look through a huge diff of tomorrow ... and the day after that ... :innocent:
Miroslav Nikolov
@moubi
😀 well said Andreas.
Miroslav Nikolov
@moubi
How about testing-library? Does anyone have a hands-on experience with it?
I am missing the human readable syntax there, though.
@sunesimonsen will be thankful for your elaboration whenever you find time.
Sune Simonsen
@sunesimonsen

So about testing-library. unexpected-dom is actually compatible to some extend with testing-library, you can use it for rendering and interacting with the DOM and use unexpected-dom to assert the DOM structure if you want.

About mocking and stubbing. I mock the network layer and just render components in a context where they have a fake network. It can be tedious depending on what kind of stack you are using, so if you can tell me that, then I might have some inputs. It is quite different what I would do with Redux and Apollo client.

Sune Simonsen
@sunesimonsen

I usually don't create about the DOM structure of the components that I use, we have a shared component library and that is fully tested, so I mainly test the semantics of the feature I'm bundling. I do that by using test ids and poke at the components to get them in the state I would like.

But I personally think we as a community have put way too much logic into React, so if you are on Redux as an example I would try to get as much logic into Redux as possible. That would make it possible to test all of that logic there, then you can mount your components with the state you want to present just by providing a Redux store. Your React components can be dumb and presentational as they were suppose to be. I know this is probably very hard to apply, but I think we went in the wrong direction with React.

Miroslav Nikolov
@moubi

Yes, you are right, it really seems the direction shift. I recently read the react-redux docs and their recommended approach is not longer sticking to separation of concerns with something like connect() but go for the hooks API instead. I have tried the Redux hooks in a recent project and had to change pretty much the setup of the tests.

A test looks something like that (sorry for the morning shot of code):

it("should call openDialogAction", () => {
      [SomeComponent, store] = withStore(
        SomeComponent,
        merge({}, initialState, {
          overview: {
            data: {
              plan: {
                name: "Plan A",
                total: 100,
                usage: 100
              }
            }
          }
        })
      );
      store.dispatch = sinon.stub().named("dispatch");

      const component = mount(<SomeComponent />);

      simulate(component, {
        type: "click",
        target: "[data-test-id=upsell-link]"
      });

      expect(store.dispatch, "to have a call exhaustively satisfying", [
        { type: "@ui/DIALOG_OPEN", payload: { dialogName: "PLANS_DIALOG" } }
      ]);
    });
It's a hassle to setup the store like that for almost each test and not easy to test for specific compound store actions.
Sune Simonsen
@sunesimonsen
In theory you should be able to have completely dumb React components that only dispatch actions and is completely directed by store. I know that it is probably not the reality. Then you should be able to render your React component with the state specified in the store, and test that it calls dispatch when you click things. The rest you can test in the store.
The reason for even talking about this idealistic approach, is that I'm actually trying to make a state library and view library similar to Redux and React that enforces that pattern, so that is very much on my mind :-)
In the library I'm creating you can't have component local state at all.
The code you show can easily be replaced with something that something like this:
expect(SomeComponent, 'rendered with state', {...}, 'to satisfy', ...)
Sorry if what I'm talking about is a bit abstract.
  • My advice is to move as much logic to Redux as possible and test it there.
  • Test that components dispatch the correct actions when clicking on things.
  • Test that components contains the correct test ids when rendered for a given state.
Sune Simonsen
@sunesimonsen
Hope that make some kind of sense.
Miroslav Nikolov
@moubi
Yes, very helpful thanks.
I suppose we will then use uncontrolled forms fx. with that approach.
Waiting for your new library to emerge :)
Sune Simonsen
@sunesimonsen
You can see how I would test a model to completeness here https://github.com/sunesimonsen/depository/blob/main/examples/todomvc/test/todo.spec.js that leave very little room for errors in the rest of the program as everything happens around the store. But you can of cause still wire things incorrectly.

I suppose we will then use uncontrolled forms fx. with that approach.

You can still use controlled forms, but you have to dispatch the changes, or you have to keep that state locally and dispatch it on submit.

In my library you have to dispatch as or use uncontrolled state as there is no other state :-)
It requires a pretty difference approach to tackle problems, so I don't know if I would advice you to go back to work and say that that is the golden path :sweat_smile: But it creates a lot of great capabilities, like being able to time travel your entire UI, decoupling of UI parts as they communicate solely through state. Downside, you need to give things ids (you will end up doing that anyway for tracking).
Miroslav Nikolov
@moubi
Interesting, I got your idea.
Giving it some time to digest :)
Miroslav Nikolov
@moubi
Ok, so styled components that are dispatching...
Sune Simonsen
@sunesimonsen
Yes (not as in styled-components 😅)
Miroslav Nikolov
@moubi
yes :)
Do you then pass store data the usual way with props?
Sune Simonsen
@sunesimonsen
I'm trying to make a stack that is predictable, small enough that you can read all of the code in a couple of days and something where you can have many versions of the libraries in the page without a problem because the size is very small. I don't think the current way we do React scales to large orgs, any kind of page singleton destroys the story.

But with libraries that isn't singleton and where you can make an entire application in 6.6KB JS would allow many teams to move freely without coordination.

Haha it is all work in progress, sorry for giving you such a long writeup.

Do you then pass store data the usual way with props?

You can get data from the store and from props, but any change can only start from the store. That might propagate through props.

Miroslav Nikolov
@moubi
I see
Sune Simonsen
@sunesimonsen
Hacking on a HackerNews demo of @depository/view https://drive.google.com/file/d/137BVP3oZsL51EmG5dGqMgAqM8t1LONyG/view?usp=sharing
I simply love the workflow.
Sune Simonsen
@sunesimonsen
Andreas Lind
@papandreou
🦜:dash:
Peter Müller
@Munter
Happy birthday @alexjeffburke !
Andreas Lind
@papandreou
Glad fødselsdag, Alex! :tada: :cake:
Whoops, should be careful with the confetti right next to the cake :grimacing:
Sune Simonsen
@sunesimonsen
Happy birthday @alexjeffburke 🌟
Alex J Burke
@alexjeffburke
Thank you for those lovely wishes 💙
Peter Müller
@Munter
Happy birthday @sunesimonsen :D
Gustav Nikolaj
@gustavnikolaj
Happy birthday @sunesimonsen ! :)
Andreas Lind
@papandreou
Congrats, Sune!
Sune Simonsen
@sunesimonsen
Thanks ❤️