The vision for SnapTest

Why does SnapTest exist?

QA Test recorders and creators have been around for a long time. The most notable one is Selenium IDE which has years and years of development. SnapTest is very similar to Selenium IDE... So why did we want to build another one?

Here's why:

1. The browser automation world is undergoing major changes, and current tooling isn't keeping up. Amazing new technologies are starting to appear that may replace Selenium entirely. A couple of the hot new ones are Cypress.io, Testcafe, Chromeless, and Puppeteer. Each one has strengths in terms of being faster, more debuggable, and less flakey. This rocks! But Selenium IDE doesn't generate code for these frameworks. There needs to be a product that does.

2. Selenium IDE is not in Chrome. Seems they are stuck in Firefox for whatever reason.

3. I want more features in a QA IDE, and I don't want to make them for a dying project Selector algorithm improvements, target fallbacks, multiple test running, integration into JIRA, etc... There are so many cool things to do with a project like Selenium IDE.

4. (Most important to me!) Test project generation can be for more than just prototyping: Some people are of the opinion that Selenium IDE was only good for prototyping, and I'd agree with them for the most part. But do ALL tests, even the mundane "click on this and that" tests need hand-coding? SnapTest strives to generate the mundane aspects of a QA project, but allows custom hand-crafted tests as well.

Pros to code generation of QA tests:

• Much faster to get QA code finished.
• You can switch generators and hence frameworks.
• Non-technical people can work with technicals.
• Will always use the latest most stable code to build upon.

Cons:

• Generated code can't be changed and modified unless taken "off the reservation".
• You're at the mercy of the capabilities of the tool to define a test. This can cause frustration when some generated code doesn't work right for whatever reason...

Counter-con:

• Generated tests can live alongside manual ones if the generated code is only a portion of the project. (Think "generated" and "manually written" test folders side-by-side). This gives "Best of both worlds" between fast mundane tests, but slow and specific manually written tests.
• SnapTest is open-sourcing the code generation portion so people can update or create their own generators. Also, we're constantly expanding the actions the tool can do, and there's always the option to take the generated code and manually modify it outside the tool.

All these add up to a new product. These are the biggest reasons we believe there can be another Selenium IDE.