What is Reddit's opinion of
Cypress.io?
From 3.5 billion Reddit comments
➔ Cypress.io website
By popularity on Reddit, this Service is:
79 reviews of this app found across Reddit:
In my experience, it isn't worth it writing unit tests for components, specially if you're working on a rapidly evolving project (which is the case for most startups).
If you have complex logic in your components, I suggest you to abstract it into small functions and unit test them.
Something that is worth doing is end-to-end tests. In this case, you should take a look at https://www.cypress.io
So, first i want to say—from your brief description, it sounds like you have the responsibilities of three separate jobs: QA, automation, and devops. They are setting you up to fail by giving you so much responsibility, especially when you are not experienced in 66% of it.
If you are set on Javascript as your language of choice, then i think Cypress.io is probably a pretty good choice for you to get started. It's got a test recorder and you can watch your tests play back right out of the box, so that should be helpful.
When you feel comfortable with that and start needing to actually maintain your tests, read up on Page Object Model. It was designed as an approachable way to maintain automated test suites.
You're going to make mistakes, and have to spend a lot of time fixing them. There are just some things in automation that you only really internalize from making those mistakes and painfully fixing them.
As for the devops stuff... i really suggest they hire a devops specialist. All three of these jobs touch each other, but are distinct skillsets.
Cypress is so nice to work with. Laracast has a nice starter for Cypress with Laravel specific helpers like database seeders, csrf, login etc.
Lots of other tech companies write blogs about more advanced topics. For example, Cypress makes some pretty cool webcasts about testing strategies at scale and stuff. https://www.cypress.io/blog/2021/10/06/webcast-recording-faire-cypress/
LogRocket also writes some pretty good technical content https://blog.logrocket.com/how-to-implement-feature-flags-react/
What advantages does this have over Selenium? It looks like this only supports tests in their JS DSL, whereas Selenium/Webdriver has bindings for many languages. It also looks like the method it uses is analogous to the "old" Selenium, where it injects JS into the page, which I presume isn't as faithful an analogue of a real user than a Webdriver is
Unsurprisingly their How It Works page exaggerates the difficulty of using Selenium - of course you'll have to install a test runner to run tests! They also allude to "Selenium issues" without explaining them - for example you can run Selenium completely locally (web developers should be quite familiar with that sort of architecture)
I have found Selenium tests to be a bit brittle, but the failure was usually either Chrome autoupdating itself and breaking the Chromedriver, or timing issues that are inherently difficult to solve without a poll loop (i.e. asserting a condition before the JS has finished updating the page), so can be considered the fault of the test author
It looks like the key advantage is being able to access the Javascript internals of the page under test? That does seem very useful I agree, though one must take care to not just be writing an overcomplex unit test that doesn't simulate real user interaction
"Testing Library" (that's the name, very plain) and Jest are a pretty popular combination nowdays. This will give you a Node.js/terminal based runner experience. Just has some mocking functionality for APIs, where you mock the HTTP client generally
Alternatively, if like in-browser, Cypress have an alpha version of their component testing runner. There is a guide on setting it up with React here. Mocking is on the network level with cy.intercept.
I work on both Testing Library and Cypress - happy to give you more info on either if needed.
I don't think I'll be covering testing in this one.
Personally, I like to write the least amount of tests that cover the most amount of code. Lately I've been using https://www.cypress.io/ to test everything, but it's an end-to-end test.
Are you referring to this? https://www.cypress.io/
Is there a free self hosted plan, or is it cloud only?
Regardless, I understand the hate on web dev, I myself am extremely frustrated by the state of it (why the hell do o need to download 500 MB of dependancies for a TODO app, why is there so such a massive chain of tooling, etc).
But using typescript instead of Javascript has quelled that drastically for me, combined with solely vue as a dependency. I am very eager to shift to svelte with typescript though, since it seems to be a more tightly woven together solution and less overhead.
Cypress is a very popular testing framework which automates a real browser to perform end-to-end tests on your site. If you don't have JS to test, then that's probably your best bet.
We're not currently using Cypress, but looking to use it for e2e and integration tests while keeping component tests in Jest.
Now I just saw this and wanted to hear if anyone have tried it. Here's a link for getting started using it with React.
I'm not too happy with Jest for component testing, as I feel like it's very hard to find what the errors really are just by looking at the DOM as text.
Having only minimally experience with Cypress I however fear that it will feel heavy and bulky to spin up the whole cypress interface for testing small components.
Looking forward to hear your thoughts!
I'm not sure that another Selenium based testing framework solves anything, no matter how humanly readable it is. If it's based on Selenium/WebDriver, it comes with all its flaws. It'd go with https://cypress.io
I totally understand you. Testing Vue.js components is still a nightmare. Are you using the official vue-test-utils?
If you can choose, you might switch to cypress, which is slightly less painful.
Seems interesting. Might help if you post some links to get a grasp of what it is capable of and how it works:
It would be good to point out it also does typescript: https://www.cypress.io/blog/2017/12/11/an-alternative-to-protractor-for-angular-projects
I think this is also handy for most if they want to get their office to upgrade: https://docs.cypress.io/guides/guides/continuous-integration.html
Overall I think it looks great. Much more useful than protractor in the sense that you can even debug whats on your production/test environments and you get more than just a list of success/failures in your command line that only give an error you most often don't give an idea of whats wrong.
Definitely gonna give it a go on my personal project
There are a lot of different ways and methodologies that you can test a system. You can either do End to End Testing (E2E) which will test the whole flow at once, or you can unit/integration test smaller chunks. Unit/integration tests are cheaper and faster to make, with E2E tests being the most expensive, but can sometimes cover the most at once.
I have an SPA that I work on and we do a mixture of all of that testing. The key business logic areas are unit tested and integration tested based on mock data. Gives us solid insights on ensuring we are always processing based on certain rules through the full cycle. On the frontend, I use a tool called Cypress. There are some basic flows that I use E2E testing just for confidence that it all is working at its core in a uniform manner - usually simple CRUD flows or just navigation flows and ensuring data is loading correctly. Everything else I stub with Cypress and I remove the server variable from the testing mix.
I will tell Cypress to load up a key section of the SPA, let's say we are managing users in the system. I will tell it to add a user (and return a response that would be typical from the sever) and ensure the table loads the new data and sorts it properly. Then I will write a test to delete the user (using the same server response) and ensuring the table updates properly, or returns the right error messages if issues happen. During all of those test cases, I will usually add another test that sets a timeout for up to 5 seconds on the server response to ensure loading icons and progress bars are working.
I'd recommend Cypress for E2E testing.
Shameless plug but I also recently self-published a book that teaches you automated testing, including E2E, in Angular.
What about Cypress? I have very litte experience with frontend testing, but there have been a lot of people claiming it's much easier to use and maintain than Selenium (and then some who claim Selenium is much more powerful).
Write automated tests, using something like testing-library and/or cypress.
For example, you can test that an event listener has been removed by triggering that event and writing an assertion that the event listener function's effects didn't occur.
It sounds like you'd benefit from looking into Deployment Environments. It's common practice to have a development, staging, and production environment. It's up to you as to how to do it but development tracks the dev branch, staging tracks release candidates or mirrors the main branch, the production environment tracks the main branch. So you have to set everything up at least twice. Once you have a staging environment you can send yourself notifications from the staging environment and since staging is a mirror of production you know it'll work there as well.
Also look into integration testing and smoke testing. To test notifications it might be worth while to have an end to end test that creates a QA user in your staging environment, issues a notification, tests to see if the notification is received, and validates it. That way you have an automated way of knowing whether or not you features work.
Headless CMSs are a good solution to allow for changing copy. There are services out there that have multi channel notifications and a back-end to manage all the content already out there. Twillio comes to mind.
Check out a testing library like Cypress
Wrong Reddit, mate. Cypress has nothing to do with Vue.
Read up best practices in official Documentation: https://docs.cypress.io/guides/references/best-practices
And here‘s a good explanation on page objects vs app actions: https://www.cypress.io/blog/2019/01/03/stop-using-page-objects-and-start-using-app-actions/
Test writing is definitely a hard mindset to get into but it's a very valuable skill to have, so good on you!
It's also important to remember that sometimes a unit test isn't the right tool for the job; if a component is complex enough that it requires an insane amount of mocking, I would recommend looking into integration tests. Cypress is a really great tool for that!
Honestly, it's been a loooong time since I started, and I'm from a different country where there's alternatives to college (German immigrant), so I don't want to give you any "well in *my* time!... " kinda advice when it comes to looking for an actual job :)
But as far as "learning the trade" goes, that's super easy nowadays, just kinda overwhelming to figure out where to start. I'm what's usually very broadly referred to as a "web developer", meaning I make stuff that runs on the internet (vs. like, programming the CAN bus system for cars, or creating rendering software, or any of the other thousands of software applications out there).
Web development is pretty easy to learn, all is done in JavaScript or some framework on top of it (React, Angular, etc), tons of tutorials out there (or bootcamps if that's your thing). Another approach might be to look into software testing, check out https://www.cypress.io/ for that.
You can pick up small (very badly paid..) software dev jobs on sites like Fiverr or Upwork, that could help you get started on some actual paid work (not really an option for an actual career, though, it's way too competitive on these sites). But that'll help you "learn the ropes" and figure out what you wanna do.
If you can still work as a mechanic for a year or two, I'd suggest learning some software dev on the side, maybe make a new website for your shop or for some friend's business.
To me, Jest/Enzyme sounds good in terms of performing unit tests on the individual UI components themselves. I’m not sure if I would actually use it for integration testing.
Ideally the apis should be unit tested independently from the UI components (jest would be fine here too for assertions).
It sounds like though you have a custom orchestration container built for this, I wonder if this is really truly testing integration if you’re not running this in some type of environment closer to browser like. Your software will be expected to run there (not doing so may hide integration issues between browser and JavaScript, for example feature support in a particular browser).
Selenium or Cypress (https://www.cypress.io) does sound like the way to go.
You want either a library that can run Selenium for you, like Nightwatch, or Cypress.
Selenium is an older technology for browser automation that lets you load and run through pages as a user would, in any browser. It's very, very solid, and should work absolutely fine with server-side rendered views, but can sometimes be a bit slow and can become tricky with pages that rely on a lot of client-side JS.
Cypress is a newer technology that allows you to do the same kind of browser automation as with Selenium, but it's entirely based on Chromium so it doesn't work cross-browser. It has a great UI for running tests locally which can make it easier to understand and debug issues, and it works better with client-side JS because it's operating in the same UI thread as your actual Javascript.
This kind of testing is usually called end-to-end testing, or sometimes acceptance testing, but frankly there are dozens of different words for the same kinds of tests and it doesn't really matter that much.
Cypress has good documentation, blog posts, and even videos. I suggest that you start there.
They also recommend not to use the page model: https://www.cypress.io/blog/2019/01/03/stop-using-page-objects-and-start-using-app-actions/
I was never sold on storybook as "testing". It's very good, but it's more just a development environment - it doesn't actually automate or test anything. If you have to verify it manually, it's not really testing (well, it's manually QA - effective but expensive).
Cypress component testing and something like Percy (regression testing) solves 90% of these problems. I made a a video about this.
Disclosure, I work on this product. I also work on Testing Library, too.
Functional tests aren't unit tests. I'd expect refactors to break unit tests. Functional tests flex your user-facing components and can exist outside your app. For most PHP applications this can be done with code driven browser automation.
Lately I've been using Cypress to do that. If you want a PHP-based functional test suite codeception is pretty decent. If your app is a RESTful API then karate is kinda nice too.
Yea you would need to use Chai or some other assertion library for functionality. Personally, I think you should try Cypress https://www.cypress.io/
As that contains everything you need and is a joy to use imo
Probably Sikuli Project. I was not able to load the page at the moment, but this is the url http://sikuli.org/
There are alternatives like Cypress too and probably 100s more, https://www.cypress.io/
But I would rather go with a browser extension like u/WhirlpoolBrewer said
I'm having fun building a stub server, Stubbex. Among other things, it can:
- Automatically record and playback stubs
- Store stubs in an hierarchical directory layout corresponding to the URL path structure
- Template stubs using EEx
- Diff stubs against the real responses
- Do JSON Schema validation of stub body schemas against real responses
I've already written a simple frontend test using it and Cypress for an app that would otherwise need VPN access to develop; works like a charm.
Haha, I know right. Well not Svelte, only by name 🙃
I spent half the day figuring out what Docker image to use, combined with what NPM commands, just to get what Cypress to work alongside our (ancient) React build in a BitBucket pipeline. I think I needed maybe 10 lines of configuration 🤣
But yeah, learned a great deal from that, which will help me next time! 😃
I think it partly depends on the size of the application.
What you describe seems simple enough to just test the separate parts and be (quite) sure everything together works as expected.
With large(r) applications I like to rely extensively on unit tests, to ensure the individual pieces all work as expected. They’re also far easier to test and are real easy to mock.
Then I also add in some integration tests to ensure the entire functionality flow works as expected. Testing all scenarios for that is really hard, thus a limited amount of integration tests 🙃
I can’t comment much on UI testing as I have barely done that, but maybe Cypress can help when it comes to integration tests and Storybook (and Chromatic) can help with UI component testing.
Assuming this is used for valid reasons: look at https://www.cypress.io
It’s an automated test tool somewhat similar toSelenium WebDriver, which would be the other - but IMP inferior - option.
It runs in your browser, allowing you visual debugging. It also has a headless mode so you can run it in command line / pipeline.
Docker certainly helps with getting a local dev environment setup, but for testing (other than unit testing) you want an e2e integration testing. The current hotness in that regard is https://www.cypress.io/
I don't see many people mentioning QA tester, but often working in QA helps with Frontend because of the opportunities for automation.
If the company uses something like Cypress or Nightwatch, then you'll need to write tests in Javascript, and often will deal with APIs / patterns (e.g. CSS selectors) that appear in traditional frontend work.
Not to mention, being good at QA adds a lot of value to a company. You prevent the bugs from slipping into production, and it gives you a new outlook I like to call "QA Brain" where you intuitively think "how can I break this?" The benefit ends up being that a developer with a strong "QA Brain" will more than likely end up building software that is more resilient.
Two things I wish I had learned earlier in my career are DevOps (which is not that crucial, and you can not bother with when you're beginning, and was not really even a thing when I started), and automated testing / TDD.
If you are not familiar with testing, I'd recommend you check out jest. It offers pretty complete functionality (including a test runner, mocking, assertion functions, etc.) There are other tools out there, but I liked jest the most.
Also, look into Cypress. It does a different thing, which is run tests inside a browser. While jest is great for unit tests, and small functions, you can program cypress to test a variety of user actions interacting with your entire site. (It's good to have a staging server so you don't mess with live data).
Gonna drop a few links you can check out when you have time.
- Jest tutorial by Traversy Media: https://www.youtube.com/watch?v=7r4xVDI2vho
- An overview of JS testing in 2022 (medium): https://medium.com/welldone-software/an-overview-of-javascript-testing-7ce7298b9870
- Cypress: https://www.cypress.io/
We have a test suite in https://www.cypress.io/ that we run against the production server right after a deployment. The test suit registers a new user and does all the really important stuff that every user should always be able to do. If this test suite runs without problems, everything is fine and the deployment is done.
Cypress clears cookies & cache, etc. before each test.
Here's some resources that may be useful.
Dom Detachment
Custom Commands
Real World App w/ Tests & Examples
I use cypress. You do write tests in JavaScript, but I use it for both testing my apps that I’m building, and testing applications we use in the office to ensure everything is working.
REMOTE, OPEN SOURCE
Join us at Cypress in building the future of testing! We are expanding our offering from our E2E test runner into Component Testing (React, Vue, Angular) as well as building out our Dashboard product, which gives you insight into your test performance over time, including speed, regressions etc (modern TypeScript + React code base).
You'll work on highly technical problems with really smart people. In addition, most of our code is open source.
Apply via our website, or feel free to reach out for more information or with any questions.
As @shaunpdx said you can call requests in using cy.request! This is particularly useful if you have a FE that may have post calls during, before or after your processes!
https://www.cypress.io/blog/2017/11/07/add-gui-to-your-e2e-api-tests/
I've been using Cypress to great effect for API tests. It does depend a bit on your API. I think Cypress is best at working with JSON APIs.
I just stumbled on this blog post, and the cy-spok plugin looks really promising for API tests. It's a more readable version of what I am doing with my tests. I'm going to play around with it this week!
https://www.cypress.io/blog/2019/12/23/asserting-network-calls-from-cypress-tests/
I find working within the test runner makes writing API tests, inspecting network responses, debugging tests, etc really easy. I'd advocate timeboxing for exploration of any new tool. Spend 1-2 days writing a couple of hello world API tests and compare ease of writing, speed of test execution, ease of debugging, etc.
Consider your CI pipeline.
Will it be faster/easier to run API tests as part of your integration tests? Do they need to run separately or in a different part of your pipeline? I can run my API and Integration tests at the same time in my CI pipeline, but needs vary. Your team may want to fail builds earlier if API tests fail, or fail builds for API tests, but not integration, etc.
Make a list of pros and cons based on your research, open a draft PR, and share your exploration!
I am not really happy with screenshots OR snapshots tbh. I want to know things work when you interact with them. Storybook is a neat tool though, for sure. Visual testing is a nice idea but in practice it seems a bit flaky. That said, things are getting better.
If you are interested check out the new Cypress component testing runner we launched last week. It's still pretty new and has some rough edges, but once you get past the initial bundling time (same problem as storybook, webpack is slow...) things are really quick - we are using hot reload to re-run your tests almost instantly (see the video in my previous post).
We are also working on Vite support which gives you near instant start-up time. It's not public yet, but if you want try it, pull this branch, do yarn then yarn cypress open-ct. You can develop with TS + Vue 3 + Vite and have a near instance Cypress feedback loop.
Obviously this is a bit biased, I work on this product full time - I also work on both Test Utils and Testing Library and Vue Jest, though, so I don't really have any strong feelings about one solution. I just want to test my components, and I think been able to see the component during testing is really useful.
Check out cypress if you guys are a bit flexible. It does have a semi-long startup time but you don't have to start selenium/puppeteer separately and actual test execution time is faster than either from comparisons I've seen.
The best thing though is the actual dev ui for writing tests and the auto-reload while the dev ui/runner is running.
It is a thoroughly enjoyable experience to write tests using cypress compared to literally every other tool I've used. I don't understand why anyone would use anything else, even if it meant taking the time to migrate a fairly large test set over, or bringing in another tool for net new work/tests.
We use cypress and it's awesome. In fact, we use it for both our api testing and ui testing.
The composability is pretty strong, I can create single commands for extremely complex tasks (multiple combo-boxes, full CRUD lifecycle, etc) to variablize repeatable tasks instead of having to duplicate 30+ lines of code for a set of test cases.
While the API testing may not be quite as robust as some other libraries it does enable us to use a single tool for a variety of situations which I greatly prefer when feasible.
I don't know how people actually do it, but if I were to do it, I would start at cypress.js.
It's a testing framework that lets you test webpages that you develop. Though, you can use it for anything.
So if you wanted to do a checkout process, you could easily do some tests on cheap products using $10-20 and then just point it to the pages that you want to buy stock from.
Yeah, Puppeteer is your ticket. It basically loads an actual website, Javascript and all, and then you can give it instructions to fill out the fields with whatever data file you've loaded up. (You actually could use Cypress (which is awesome!) as well, I suspect, but it's designed for testing so that's a bit of a hack.)
Unit testing is not going to happen with code like that. I would recommend browser automation testing, using something like Cypress.
For testing at the level of http requests, you could try Codeception or symfony/browser-kit (or just roll your own with Guzzle)
Which parts of the ecosystem people actually miss?
After seeing a lot of SPAs, they just don't seem to use all that many framework-specific dependencies, other than for fixing deficiencies in their frameworks.
Most big dependencies are just plain js, or reasonably framework agnostic.
>My biggest concerns are Database related
As mentioned in another post on this thread, your unit tests shouldn't be hitting a database for any reason. Eloquent is extremely well tested and doesn't need any more unit tests. If your single piece of code does need some kind of object to work with then you need to look into mocking that object to run your tests against that.
If your unit test is hitting the database it's very likely your unit test isn't testing a single unit of code.
From what I can gather from your post, although it's not fully clear, you're trying to test multiple blocks of code in a single test. This is moving more into the integration/acceptance testing area rather than unit testing.
Although PHPUnit can do some level of integration testing it certainly isn't as robust as a dedicated solution. Laravel has one built-in called dusk, although the industry standard is Selenium. A relatively newcomer to the game is cypress, I've used it in a recent project and was impressed by its ease of use, especially compared to selenium.
In my opinion - learn Cypress, and get good with it. It is a very desired skill to have that employers are seeking out. Selenium is just too outdated and flaky.
Hello there. If I understood correctly your sign up form is inside an iframe.
Working with iframes is not very easy in cypress, but you can read this https://www.cypress.io/blog/2020/02/12/working-with-iframes-in-cypress/
I hope that helps you.
My recommendation is that you visit the page in the iframe src and test it as it was not an iframe, it should be easier and the outcome is most likely the same.
As for the second question I didn't really understand it. Can you please elaborate?
Hmm check out the docs - https://www.cypress.io/
I would consider integrating the CLI into your project. It's really helpful for stuff like this. Also, if this is going to be a big project, you're probably going to want to leverage other features of Vue. Like Vuex or VueRouter - these things can be simply added in via the CLI, so it will help for scaling
https://www.cypress.io/how-it-works
Cypress popped in my mind as I read this. It's an easy to set-up end to end testing tool. It's not always ideal since it only functions on Chrome, thus not really doing a well covering test for web applications. But for something like content comparisons it should function fine.
Cypress is a much better product IMO if you want web testing https://www.cypress.io/ it's node, and they recently added beta Firefox support, you also get screenshots, videos, and xml test results you can use in a ci environment. It's node based but i found it easy to work with.
Selenium is fraught with inconsistencies from client to client if you're not doing Java in my experience, i spent more time fighting the tool than being productive.
Not specific to the esri API, but for many map-based web apps we have found a lot of bang for the buck in using Cypress to do integration and end to end testing. We avoid trying to write complicated unit tests for the map interactions, and leave those for logic functions and other UI elements.
I can start from what I already tested: Percy. It doesn't fit my needs because it's not free although their free tier is kinda nice. It works by leveraging your testing tools and just sending HTML + assets to their servers where they render the screenshots in chrome/firefox for your desired resolutions.
The whole flow is kinda nice and simple enough. It also works if your app requires you to login. I really don't like sending HTML + assets to their servers and on my specific test there are rendering issues (some missing images).
I would prefer a more 'local' tool and of course, more 'free' :)
No. It is useful for Cypress too especially if you want to keep your tests atomic and maybe refactor application model code instead.
https://www.cypress.io/blog/2019/01/03/stop-using-page-objects-and-start-using-app-actions/
This is a general post about web scraping and python. How did everyone get sidetracked on selenium and integration testing? Web scraping with selenium does have other use cases than testing.
All the alternatives raised, Cypress, Puppeteer, and Playwright are all NodeJS projects. How or why would I use a NodeJS library in a Python project?
I am serious about the question in #2. How or why would I do that? What are the use cases for it?
EDIT I could see the use for Playwright or Puppeteer because they're strictly just libraries for selenium activities but Cypress is specifically for tests, also if someone is unable to just up and switch to (or add) NodeJS those are useless.
Hello browat,
in my last job i worked as a frontenddeveloper for a huge German insurance company. I was coding the new intranet webpage for the employees. The project was a "agile scrum" project. So the dev team had 3 weeks to implement new features, test them and publish them. The page had over 12.000 useres a day and was necessary for the company.
Because we were only 7 developers for this page it was a huge problem for us. We were developers and testers and codereviewers at the same time for each other. Now when you implement a new feature it happens very often that it effects some design things or elements on other pages you don't expect.
Bugs in production where a huge problem because we were only able to publish every 3 weeks on prod.
So we started to write tests with Cypress. And this worked great! Everytime when someone finished a feature with codereview and human test he wrote a unit test for it. Just simply opens a test page click a little bit around und seraches for the div containers and clicks on clickable things.
Everytime we build the product at the end of the 3 weeks, our unit tests start all together. If one failed - then the build failed until we fixed the bug.
So at least we could bring our bugs per publish to a very impressing low.
As said, we used Cypress for testing. It is very good documented on his webpage: https://www.cypress.io/ just take a look at it.
For our building process/pipeline we used jenkins but this depends on the size of your project.
I hope i could help you a little bit with your research:) Have a nice day!:)
Maybe test in layers: e2e user stories only via UI. Then API calls (spy on them), then if needed you can access the internal data to confirm it. https://www.cypress.io/blog/2017/11/28/testing-vue-web-application-with-vuex-data-store-and-rest-backend/
In my opinion it makes the most sense to write your automation tests in the same language as your application when possible.
Fortunately, there are a lot of nodejs frameworks that are really easy to get started with, have a look at
or
To write tests you probably want to learn a bit of basic javascript, and then maybe take a course on one of the above, or just play around with it (If its your first time, I'd probably recommend nightwatch)
As already mentioned, Can I Use is a great resource to check compatibility. Generally speaking though, avoid cutting-edge things. Flexbox is fine. Grid is probably ok depending on your target audience. Speaking of them, you should run analytics to find out what browser versions your users are using. Google Analytics is popular.
When you do write your code, you should run your JavaScript through babel and your CSS through auto-prefixer or a similar tool to ensure as much compatibility as possible.
Also, you should test different screen resolutions. You can simulate mobile, tablet, and other screen sizes as part of your development.
Lastly, you should do some testing to ensure everything is working. There's many different ways to do testing, but based on your description I would recommend end-to-end testing with Cypress.
You could look into using browser automation software like Selenium or Cyprus.
You could also look into web scraping.
I can recommend you Cypress. It is far more stable and easier to learn than Selenium. I had no experience in automation and setup the whole framework and a full automated smoke check for our software within half a year. Their documentations are great, it also has a great community. Also on stackoverflow a lot of people can help you, because Cypress is used by a lot of people.
I've used WebdriverIO and CodeceptJS it's not the testng syntax that I'm criticizing. You can use any automation API to write without much difficulty.
What I love is the test runner that takes DOM snapshots which makes debugging easier, and built-in stubbing support.
I a firm believer of using the right tool for the job and if I had to automate IE or mobile devices I wouldn't use Cypress, but if it's just chrome then I would do an analysis of alternatives at your company.
I wouldn't agree with anyone saying that it's a selenium killer since every tool has trade-offs.
Without a source I would challenge your assertion that "very little people seem to understand that selenium is an API and Cypress is a framework" https://www.cypress.io/how-it-works makes it clear that it's a batteries includes solution
I do think their popularity is due to better marketing, but I also think developers like it more so people talk about it a bit at tech conferences.
Do you use a cloud-based selenium grid? Getting the Microsoft browsers working was challenging
Test cafe also seems interesting.
I created a web scraping module in Python to distribute page scraps across multiple tabs in Chrome using Selenium. It works like this, although I didn't know Apify existed at the time. I actually based it off Cypress.
​
Basically, you setup up Page classes in Python and then queue a list of executions. Then, all you have to do is pass a list of URLs into a scrape function within the Page class, and off it goes. I set it up to automatically switch between tabs between loading and parsing. For example, if you're currently parsing the data on the website, you can be assured another link is loading in the background waiting to be parsed.
It's super neat, and probably the fastest Selenium parser I've found. I'm looking to release it soon. Unfortunately, it's still in the pre-alpha stages and I have a lot of documenting to do :(
Selenium: https://www.seleniumhq.org/
Cypress: https://www.cypress.io/
Those are testing frameworks designed for testing browser based applications.
I just thought of another tool, tampermonkey https://www.tampermonkey.net that lets you add scripts directly to your browser.
I'm not sure that I understand your requirements fully but to me it sounds like what you actually want is some kind of end-to-end testing.
If this is the case then you may find Cypress useful. You can manipulate the DOM in your tests and run assertions checking state/visibility/etc for certain elements.
I think the DB state thing is an interesting approach, but I think it might make debugging hard. Imagine you run 200k requests from your server logs over your app and then compare the db state at the end, how do you know which request broke the test?
Despite complaining about status codes, I think for the quick and dirty test that this is, I would use something simple like that. When everything comes back 500 you know you'll know what's broken.
You just need to keep in mind that there will be 2 issues involved for this kind of test:
- False negatives - your test passes but it actually should failed (eg. as described in my previous comment)
- False positives - your test fails but it should have passed (eg. actual user was already logged in, test request user is not logged in, you get an auth error)
If you throw together a simple prototype and then find that you've got too many of either of these, or that they're taking too much time to track down, then I'd suggest just buckling down and writing proper integration tests with something like Cypress (Assuming you have a frontend).
I've gone the e2e (End-to-End) testing route. I wanted to replicate what I would do manually for a sanity check, to make sure nothing is broken.
The absolute best tool for this I've found is <strong>Cypress.io</strong>.
The tools they've built for replay, interacting with elements mid-test, watching tests play out live, have been a massive timesaver.
Maybe try Cypress.io test runner - you can do both E2E and API testing and treat your backend as a black box. We have good docs and it should be simple to start. For your particular case, this is a good blog post https://www.cypress.io/blog/2017/11/07/add-gui-to-your-e2e-api-tests/ and we are working on improving the API testing experience.
Integration testing on the Frontend is done using tools like Selenium or Cypress nowadays. Cypress is more and more becoming the preferred option. If you know JavaScript then you can write integration tests using Cypress's framework.
Integration testing frameworks all work the same way - you're selecting page elements such as buttons or form fields very much like you would in jQuery. Next, you're performing actions on those elements. From clicking things to simulating typing into a form field and much more.
A good example would be logging a user in using their email and password. You need to simulate typing in their email and password. Finally you need to click the login button. You would write an automated test which does these actions.
Like unit tests, you need to assert a certain post-condition exists after the above actions have taken place. This is usually done using an 'expect' function. You need to verify that the user has logged in by confirming that you are on the dashboard and the user's name appears in the header.
The flow is:
1) Setup a pre-condition
2) Perform some actions
3) Verify the post-condition
4) Do some automated clean up (optional)
Repeat for each test.
More on Cypress https://www.cypress.io/
Oh - one thing.
I've been getting pretty frustrated with Enzyme. I think Cypress might actually be more appropriate and easier to work with.
Cypress has better documentation, and more importantly, actually allows you to create tests that test the functionality from the *user's perspective*.
​
Try Cypress.io test runner. Example checking of the data going to the server and back: https://www.cypress.io/blog/2017/11/28/testing-vue-web-application-with-vuex-data-store-and-rest-backend/
You can test Vue components using full browser via Cypress (use this adaptor https://github.com/bahmutov/cypress-vue-unit-test). See this blog post https://www.cypress.io/blog/2018/04/02/sliding-down-the-testing-pyramid/ and video https://youtu.be/5FnalKRjpZk)
I currently do my tests with cypress, if everything is ok on the front-end the api is fine. On the other hand, a great tool is apollo-engine that allows you to make important follow-ups to the performance of a GraphQL endpoint. But, take a look to this article
Even though it is not released, I recommend checking out cypress.io, https://www.cypress.io/
I guess it is somewhere in the middle of scraping and Selenium, but far more easier than selenium in terms of setting up and writing tests etc.