Alternatives to jsdom

When you think about test automation, it’s crucial to make it everyone’s responsibility (not just QA Engineers'). We started with Selenium and Java, but with our platform revolving around Ruby, Elixir and JavaScript, QA Engineers were left alone to automate tests. Cypress was the answer, as we could switch to JS and simply involve more people from day one. There's a downside too, as it meant testing on Chrome only, but that was "good enough" for us + if really needed we can always cover some specific cases in a different way.

For our digital QA organization to support a complex hybrid monolith/microservice architecture, our team took on the lofty goal of building out a commonized UI test automation framework. One of the primary requisites included a technical minimalist threshold such that an engineer or analyst with fundamental knowledge of JavaScript could automate their tests with greater ease. Just to list a few: - Nightwatchjs - Selenium - Cucumber - GitHub - Go.CD - Docker - ExpressJS - React - PostgreSQL

With this structure, we're able to combine the automation efforts of each team member into a centralized repository while also providing new relevant metrics to business owners.

We use CasperJS because we adopted it back in 2013 for JavaScript frontend testing. It was a really nice system back then compared to what else was out there; you had PhantomJS as a programmable browser that actually rendered CSS and everything, it was really fast (speed is a big downside of e.g. Selenium), and it was possible to make non-flaky frontend integration tests with it.

I wouldn't recommend it today, because PhantomJS is a basically dead project, and as a result, so is CasperJS. I expect we'll migrate to something else. We haven't in large part because 95% of our new tests are written with a simple Node.js-based unit testing framework we use that run 35K lines of unit tests covering most of our JS codebase in 3.6 seconds. And for the things where we want an integration test, CasperJS does work, and I think there's a good chance that waiting another year or two will result in our being able to switch to a much better option than what we'd get if we migrated now.

We use Jest because when we rebooted our "front end" stack earlier last year, we need to have a testing solution (we didn't have any front-end tests before that!). Jest is fast and convenient and it has plenty of community support behind it. It let's us run our unit tests with Enzyme and snapshot tests.

This is an area that we are constantly reviewing to see what can be improved, both in terms of developer needs, accuracy, test maintainability, and coverage.

I'm currently exploring using React Storybook to be the record of snapshot tests and using some online services, such as Happo.io and Percy in our CI pipeline.

I use both mocha and Jest because:

• I don't care whether teams use Jest or Mocha. But jest is way too overhyped. Most devs are writing integration tests and think that it's so much better but frankly I don't write integration tests as the way to get both design feedback and confidence when I code. I adhere to the test pyramid, not ice cream cone or the dumb "trophy"

• I TDD, so I only ever use the "API" of test frameworks. I don't do a lot of integration tests for TDD and all the bells and whistles Jest provides you from the command-line I just don't need. And I certainly do not care about or touch Jest Snapshots, I despise them

• My tests are fast enough because I write isolated tests with TDD, so I don't run into performance issues. Example: I write my tests in a way that I can run 300 tests in literally 1 second with mocha. So the Jest ability to pinpoint and only run those tests which are affected by code changes. I want to run all of them every time when I TDD. It's a different mindset when you TDD

• I also mainly code in IntelliJ or WebStorm because I feel the tools in that IDE far surpass VSCode and I also love running the test UI runner in it vs. lousy command-line

• I feel both mocha and Jest read just fine in terms of code readability. Jest might have shorter assertion syntax but I don't really care. I just care that I can read the damn test and my tests are written well and my test descriptions, as well as the code itself including constants represent business language, not technical. I care most about BDD, clean code, 4 rules of simple design, and SOLID

• I don't like using mock frameworks so no I don't use Jest's Mocking framework. I don't have to mock a lot in my tests due to the nature of how I strive to code...I keep my design simple and modular using principals such as clean code and 4 rules of simple design. If I must mock, I create very simple custom mocks with JS

• On the contrary to the belief that integration tests and mount are the way to go (this belief drives me absolutely crazy, especially Dodd's promoting that), I TDD with shallow & enzyme. My tests are simple. My design is driven by my tests and my tests give me quick and useful feedback. I have a course I'm working on coming out soon on TDD with React to show you how to truly test the FE and why the ice cream cone and trophy suck (you're being scammed people). Watch for that here: https://twitter.com/DaveSchinkel/status/1062267649235791873

Don't forget to upvote this post!

Mocha Jest JavaScript React @jsdom Enzyme #tdd #bdd #testdrivendevelopment

Currently, we are using Protractor in our project. Since Protractor isn't updated anymore, we are looking for a new tool. The strongest suggestions are WebdriverIO or Puppeteer. Please help me figure out what tool would make the transition fastest and easiest. Please note that Protractor uses its own locator system, and we want the switch to be as simple as possible. Thank you!

I work in a company building web apps with AngularJS. I started using Selenium for tests automation, as I am more familiar with Python. However, I found some difficulties, like the impossibility of using IDs and fixed lists of classes, ending up with using xpaths most, which unfortunately could change with fixes and modifications in the code.

So, I started using Puppeteer, but I am still learning. It seems easier to find elements on the webpage, even if the creation and managing of arrays of elements seem to be a little bit more complicated than in Selenium, but it could be also due to my poor knowledge of JavaScript.

Any comments on this comparison and also on comparisons with similar tools are welcome! :)

Test automation - Puppeteer is used currently, just rudimentary stuff, but considering the better choices with Playwright?

We use CasperJS because we adopted it back in 2013 for JavaScript frontend testing. It was a really nice system back then compared to what else was out there; you had PhantomJS as a programmable browser that actually rendered CSS and everything, it was really fast (speed is a big downside of e.g. Selenium), and it was possible to make non-flaky frontend integration tests with it.

I wouldn't recommend it today, because PhantomJS is a basically dead project, and as a result, so is CasperJS. I expect we'll migrate to something else. We haven't in large part because 95% of our new tests are written with a simple Node.js-based unit testing framework we use that run 35K lines of unit tests covering most of our JS codebase in 3.6 seconds. And for the things where we want an integration test, CasperJS does work, and I think there's a good chance that waiting another year or two will result in our being able to switch to a much better option than what we'd get if we migrated now.