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.
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.
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.
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.
My advice would be don't use all the fancy stuff. You really don't need to. A basic HTML page with a few <script> tags will go a long way. And with browsers supporting most of ES6 (WebKit supports all of it) you can use all the new JS features in your dev environment no problem.
Don't introduce these dependencies if you're just learning. Just use what you need (React + Redux).
I've always had issues with Mac WMs in the past. They either promise too many features and end up being buggy (because they didn't take the time to solve the problems that Swindler does first) or they're too simple and don't let me do what I want to do.
This promises to solve a lot of the problems I've encountered in the more advanced WMs and might actually make a sophisticated WM on OS X possible.
Really interested to see what WMs get built with a framework like Swindler.
While I think there is some grandiose and hype that gets attached to these fields by the media, you have to recognize that these names represent the end goal of the field, not the current status of where we are today.
No, computer vision researchers haven't achieved what you and I perceive as vision, no more than a biochemical research in cancer cures have found a cure to cancer.
But I would argue that these lofty named fields are a good thing. Academia is already plagued by it's uncertainty and lack of an inherent "end game." Let's not make it worse by renaming machine learning to "computer pattern recognition." Pattern recognition is just a possible piece of the puzzle or step in the process to creating AI, not the actual holy grail of achievement.
I really like the author's analogy to a "communal sausage." Working at a company where our main backend is built on Rails / Ruby, security can always be a bit scary (though has gotten much better in recent history).
I'm fairly security ignorant, so maybe someone can enlighten me here, but why is the statement "traditional security tools aren’t effective" true? What kind of tools are we talking about? How would blackbox testing be different if the underlying software is changed?
I can definitely see how lower-level parts of the infrastructure would need to be tested differently, but I don't know what changes at the webapp-level.
http://phabricator.org is actually really great. It started in-house at Facebook. We've been using for the better part of year and I absolutely love it's code and design review tools. It also has a really nice CLI for managing your different reviews. Oh, and you don't have to worry about actually hosting the repos yourself (not worth the headache to me), you can just connect it to your github repo.
Don't be scared by the fact that it's done in PHP. It's actually really well done is very active in bringing out new updates and features.
This is my first side-project I've taken the time to productize and I could definitely use your feedback!
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)