[FEEDBACK NEEDED] Adds jest test:snapshot task

[jbalsas]

Hey guys, I'm just opening this to start a discussion about adding some kind of jest pipeline to our test infrastructure. This should be specially beneficial for component/snapshot testing. I've pushed an example commit to deprecate/metal-clay-components@ea4db2e as well after locally linking this version of gulp-metal.

What I'd like to discuss is:

• Does it make sense to integrate jest into our current karma+mocha setup?
• If so, what would be the best way?
• It's not trivial to use jest for real browser testing, so just porting all the tests there is out of the question... or is it?

What do you guys think?

/cc @eduardolundgren, @Robert-Frampton, @brunobasto, @julien, @izaera, @mthadley, @bryceosterhaus, @ethib137

[mthadley]

@jbalsas This definitely looks like a step in the right direction to me.

For the commit over on metal-clay-components, I personally think some kind of pretty printing of the output is completely necessary, otherwise it becomes very difficult to debug failures, or even initial snapshot commits. However, we can talk about adding/moving metal-jest-serializer later.

Just throwing in my opinion here:

I'm very in favor of switching over to jest entirely. So far I have almost nothing to say but good things about the framework. And it's development is extremely active right now. They very much value developer productivity and happiness.

I personally don't see browser testing is an important feature to have, anymore. jsdom does a great job in my experience, and I really don't miss browser tests at all. Javascript execution seems identical. I can't think of any bugs that only manifested themselves in the browser and not in the jest environment.

Browsers are converging much faster every day, and I rarely find differences when it comes to javascript anymore. Whenever I do encounter cross-browser bugs, it's almost always related to CSS, not javascript.

Of course, I'd live to hear more opinions about this, since I have a feeling I might be living in some kind of bubble when it comes to these kinds of issues.

[bryceosterhaus]

I'm very in favor of switching over to jest entirely. So far I have almost nothing to say but good things about the framework. And it's development is extremely active right now. They very much value developer productivity and happiness.

I personally don't see browser testing is an important feature to have, anymore. jsdom does a great job in my experience, and I really don't miss browser tests at all. Javascript execution seems identical. I can't think of any bugs that only manifested themselves in the browser and not in the jest environment.

🎉🎉🎉🎉
This sums up my thoughts pretty well. Thanks @mthadley!

[brunobasto]

Browsers are converging much faster every day, and I rarely find differences when it comes to javascript anymore. Whenever I do encounter cross-browser bugs, it's almost always related to CSS, not javascript.

If we take most recent versions of major browsers as an example, I would agree. But I guess that will depend on what our browser support matrix looks like..

[julien]

I think using jest is a great idea.

Here's my feedback

Does it make sense to integrate jest into our current karma+mocha setup?

I think it does; however I also feel it falls between two stools because you might want to use jest or karma+mocha but not necessarily together.

If so, what would be the best way?

Dependeping on the project you could decide if jest or karma+mocha is the appropriate tool to use for testing. But I also think this needs more thinking and talking, we've probably got a lot of ideas and experience to put in common. I'm convinced that together we can find the right solution.

It's not trivial to use jest for real browser testing, so just porting all the tests there is out of the question... or is it?

If porting our current tests to jest has a benefit, then it seems like a good investment. Writing more web driver tests seems to be a good solution, and could also improve the workflow between developers and QA teams.

Although I'd really like being able to do all testing outside of the browser (it's and ideal environment for developers), I still think "browser testing" is necessary: some issues are reported in specific browsers, and for developers, it's still nice to be able to see what's going on before handling the task to QA engineers. There are also new features getting rolled out in browsers which aren't always immediately available in node or simply not implemented (e.g. WebComponents, WebRTC) and although it's very easy to debug in node (using --inspect / --debug-brk) testing against a "fake" DOM doesn't always feel the same as testing in a "real" browser, or at least that's the experience I've had when using jsdom - If web driver tests have our backs covered on that side, then it's not really an issue.

Thanks!