Cypress.io vs Cedar comparison of testing frameworks
What are the differences between Cypress.io and Cedar?

	Cypress.io https://www.cypress.io/	Cedar https://github.com/cedarbdd/cedar
Programming language	JavaScript	Swift
Category	End-to-End Testing, Intergration Testing, Unit Testing	Unit Testing
General info	Cypress users are typically developers or QA engineers building web applications using modern JavaScript frameworks. This is the top tier UI automation framework which outsmarts Selenium based frameworks in most of the aspects! Cypress enables you to write all types of tests: 1. End-to-end tests; 2. Integration tests; 3. Unit tests; 4. Cypress can test anything that runs in a browser; Apart from that Cypress provides the Dashboard facility for CI/CD	Cedar is a BDD-style testing for swift using Objective-C Cedar is a BDD-style Objective-C/Swift testing framework that has an expressive matcher DSL and convenient test doubles (mocks). It provides better organizational facilities than the tools provided by XCTest/OCUnit In environments where C++ is available, it provides powerful built-in matchers, test doubles and fakes
xUnit Set of frameworks originating from SUnit (Smalltalk's testing framework). They share similar structure and functionality.	No	Yes Cedar is an xUnit style framework
Client-side Allows testing code execution on the client, such as a web browser	Yes This is the primary goal of Cypress, it tests anything that runs in a browser and works to build great user experience that is it tests the applications flow from beginning to end from a user's perspective. It is built to handle modern JavaScript frameworks especially well and also works equally well on older server rendered pages or applications	Yes You can test front-end components and behaviour with Cedar, its language is biased towards describing the behavior of your objects.
Server-side Allows testing the bahovior of a server-side code	Yes Although Cypress is not a general automation framework, nor is it a unit testing framework for your back-end services, It can test back-end behaviours for example using cy.task() command which provides a way for running Node code, so you can take actions necessary for your tests outside of the scope of Cypress	Yes You can test back-end components with a bias towards their expected behaviour. Cedar specs also allow you to nest contexts so that it is easier to understand how your object behaves in different scenarios
Fixtures Allows defining a fixed, specific states of data (fixtures) that are test-local. This ensures specific environment for a single test	Yes Cypress has inbuilt fixtures capabilities or example using the command 'cy.fixture(filePath)' loads a fixed set of data located in a file	Yes Cedar has beforeEach and afterEach class methods which Cedar will look for on every class it loads. You can add these onto any class you compile into your specs and Cedar will run them
Group fixtures Allows defining a fixed, specific states of data for a group of tests (group-fixtures). This ensures specific environment for a given group of tests.	Yes Cypress can create group fixtures using the 'cy.fixture' command	N/A
Generators Supports data generators for tests. Data generators generate input data for test. The test is then run for each input data produced in this way.	N/A	N/A
Licence Licence type governing the use and redistribution of the software	MIT License	MIT License
Mocks Mocks are objects that simulate the behavior of real objects. Using mocks allows testing some part of the code in isolation (with other parts mocked when needed)	Yes Cypress comes built in with the ability to stub and spy with cy.stub(), cy.spy(), It also automatically bundles 'sinon', 'lolex' and 'sinon-chai' which all work to give Cypress mocking capabilities	Yes Cedar contains inbuilt mock/test double functionality
Grouping Allows organizing tests in groups	Yes Cypress allows you to configure tests into groups however there is no way currently to run the groups	Yes Cedar supports shared example groups. You can declare them in one of two ways: either inline with your spec declarations, or separately.
Other Other useful information about the testing framework