Mocha vs Selenium: What are the differences?
"Open source", "Simple" and "Promise support" are the key factors why developers consider Mocha; whereas "Automates browsers", "Testing" and "Essential tool for running test automation" are the primary reasons why Selenium is favored.
Mocha and Selenium are both open source tools. Mocha with 18K GitHub stars and 2.43K forks on GitHub appears to be more popular than Selenium with 14.7K GitHub stars and 4.92K GitHub forks.
MIT, PedidosYa, and HubSpot are some of the popular companies that use Selenium, whereas Mocha is used by Sellsuki, Onedio, and triGo GmbH. Selenium has a broader approval, being mentioned in 770 company stacks & 425 developers stacks; compared to Mocha, which is listed in 397 company stacks and 268 developer stacks.
What is Mocha?
What is Selenium?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Mocha?
What are the cons of using Selenium?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
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!
We used to Mocha for as our primary Node.js test framework. We've now switched to Jest and haven't looked back.
Jest is faster and requires less setup and configuration. The Mocha API and eco-system is vast and verified, but that also brings complexity.
It you want to get in, write tests, execute them and get out, try Jest 😀
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 JUnit and Jest to perform the bulk of our automated test scenarios, with additional work with Apache JMeter for performance testing - for example, the Atlassian Data Center compliance testing is performed with JMeter. Jest provides testing for the React interfaces, which make up the backend of our App offerings. JUnit is used for Unit Testing our Server-based Apps. Mocha is another tool we use.
I chose WebdriverIO and Appium to implement a E2E tests solution on a native mobile app. WebdriverIO goes well beyond just implementing the Selenium / Appium protocol and allows to run tests in parallel out of the box. Appium has the big advantage of supporting iOS and Android platforms, so the test codebase and tools are exactly the same, which greatly reduces the learning curve and implementation time.
가장 강력한 웹 UI / UX 테스트 툴 이지만, 문제도 많다. iframe 안에 있는 건 잘 select 가 안되기도 하고, 화면이 작아 컴포넌트가 화면에 보이지 않으면 또 select 할 수 없다. 하지만 브라우저를 있는 그대로 제어 할 수 있다는 게 가장 큰 매력이다.
ps. selenide 와 같이 쓰면 코드가 많이 개선된다.
Maintaining and expanding automated regression tests is one of my primary responsibilities at CrowdTwist. We use Selenium to test the front-end parts of our platform.
Used for unit testing when working with Node.js. Used over other testing frameworks because of good compatibility with TypeScript and ts-node.
Used Selenium web-driver for automated QA testing in continuous integration and continuous deployment.
- Navigating our site for tests
- Navigating other sites that discriminate against non-human visitors
Selenium is a great way to automatically test if a build is sane and can be deployed.