I built the guts of this about a year ago to help keep on top of my team's tasks, track sprint planning, and keep on top of pending code reviews. Definitely targeted more towards Tech Leads and Product Managers. I found it useful to use every day, so I spent the time to productize it a bit more formally. Since, more people on my team at work have been using pretty much daily and found it useful. I hope you do too!

This is my first side-project I've taken the time to productize and I could definitely use your feedback!

  - Would you use this? If so, would you pay for it?
  - If not, what do you use to stay on top tasks now?
  - What other problems do you have with project management that isn't already being addressed by the gazillion tools out there?

If you do try it out, I'd love to hear more about any UX issues you run into! (I'm sure there's plenty)

I think this largely depends on how much money you are chasing and your aspirations.

I care about money not because I want to have lots of things but because I want the freedom to work on my own ideas (without selling my soul to a VC). A certain amount of money early in life can greatly change your trajectory, for better or for worse. It just takes discipline.

That still needs to be balanced, though. As you get older, you'll lose time to other things. You may get sick, injured, or die. There is no guarantee that you will have a "later".

So find the balance - live enough to be happy with today, but work enough to be prepared for tomorrow.

This is actually pretty huge. #1 complaint/barrier/hate with getting started with React is all the tooling to do it "the right way"

Kudos to React team for bringing a superior pattern and making it actually practical to use.

I'm really hoping to see the React team make React more user friendly. Maybe an all in one React framework much like Meteor, where you can just do `react createapp myapp` or something and start coding right away.

React is so versatile (raw React, React + Redux, React + Relay, to name a few) I don't think they should tie it too closely to one framework. I would love to see a more official/opinionated framework that uses React, but call it something besides "React".

Ditto for Redux. They're both low-level building blocks that could benefit from some official "opinions".

I've found beforeEach breaks down super quickly as soon as you need to change the input props. Keeping things as purely functional as possible also helps manage complexity when writing tests in a large suite. You don't have to trace through all the beforeEach of each describe/context block. That said we use a healthy combination of both, as with everything know when to use the right tool.

If your application has few or very simple interactions then this may make sense. If it does have complex interactions (I consider a text input updating a model field as complex) then I think tests are necessary, especially if working with a team. You want to know when you break things.

This becomes even more important if you're developing generic UI components that may be re-used in different scenarios throughout your app or company. These types of library components need to be well tested as they often have more complex interactions and are going to be used in potentially very different ways.

Good to know, will update the examples when I have time. Not sure I'm a big fan of it though, doesn't seem as clear to a React noob what is going on with ref?

JS tests like this are so stupid cheap that we still write them for even the most basic test. Not sure I'm convinced it's worth it yet and I might regret it the first time we refactor a larger reducer.

Agree 100%. However if you are using component state you will need to test how interactions impact rendering output on the next render pass. I wouldn't consider that implementation detail since you are only asserting against render output.

In the case of testing instance methods, this is definitely a special edge-case scenario, but actually one of the main reasons I put this together. They inevitably happen, but are rare and I tend to forget how to set those tests up.

To give you an idea of how we use this: our application is a "website designer" where the preview is rendered inside an iframe. We use a react component to push CSS changes directly into the iframe via document.styleSheets. Using instance method testing allows us to test the main output results of this functionality without having to render real iframes pointing to external server in our tests.

We haven't tried Enzyme, but we tend to prefer not adding more JS tools when we don't need to. JS is already a land of wayyyy too many tools and minimizing when possible can be a huge advantage when onboarding new devs onto a project.

Also the DOM api is actually pretty simple to use when it comes to traversing the DOM. No need for "jQuery mimicking." Keep it simple.

This is a bit off topic, but why such aversion to purpose built tools in JS land?

In my experience it's much harder to onboard devs to a custom-ish process than it is to hand them a purpose built tool with proper documentation and lots of examples of real-world usage to learn from.

I tend to try to use already made tools over doing it myself* as it makes onboarding easier, lightens my cognitive load, reduces my testing surface, and is generally quicker than coming up with my own solution.

* A bit of a disclaimer... I mean well made, well tested, and well supported tools taking into account the time cost of doing it myself, the complexity of the tool, how important/ingrained it will be in my application, the number of contributors in the project, the test coverage of the project, the speed/ease it can be switched out, how well it actually solves my problem at hand, and a ton of other things. I do not mean that you should blindly use every tools you can whenever possible, or that you should use it because Facebook/Google/Other-Company uses it.

What I should have said is "minimize tools when it makes sense" rather than "when possible." There are some tools that are more trouble than they're worth (for example, I feel this strongly about Jest).

Enzyme isn't necessarily one of those, like I said I haven't used it, but I also haven't found a need to. Some abstractions over TestUtils' event simulation would certainly be valuable.

What I am trying to present here are patterns of different testing scenarios in a format that should be useful regardless of the testing tools you may be using.

I would really encourage you to give it a try. The "jQuery mimicking" is actually not even its best feature. I didn't think much of it at the beginning, but it pretty much makes React's test utils really pleasant to work with. All in all, it basically codifies and gives a reusable api to most of what you say in your gist.

You have to learn some tool (react test utils at least) to access and interact with those React components either way. Enzyme is 100% better and more powerful than using the react test utils and way easier to onboard new devs to.

All IMO but I def think you should at least check it out.

I think you probably need to read 1984 again. Doublespeak is euphamistic political propaganda language.