With version 6.3.0, Cypress released a feature called “Cypress Studio.” It allows you to create a test script simply by opening the Cypress window and interacting with your app. If you are familiar with record & replay testing tools, you’ll probably get yourself familiar with the tool pretty quickly. So let’s see what Cypress Studio offers and what makes it different from other record & replay tools.

Getting started

Cypress Studio is still in experimental mode, so to enable it, you need to edit your cypress.json file. Just add "experimentalStudio": true and you are good to go.

To start working with Cypress Studio, create your first test file, and open it. You should now see a Cypress Studio icon in your test runner. At first, you might not even notice it, because the icon only appears when you hover over the test name.

Once you click the icon, the test runner will enter a “recording mode” and you can start interacting with your app. It will record clicks, typing, un/checking checkboxes and selecting options from a <select> element. If you accidentally do an unintended action, you can remove it.

Once you are happy with the flow you have created, you can save your commands right inside your test file. The flow you created is bounded by comments in the file, so you can clearly differ between what was generated and your own code.

Using Cypress Studio

First experience is really satisfying. You can see commands pop inside the test runner timeline. Being able to remove commands or accidental clicks is really neat and gives you a great control over the final script. Cypress Studio even seems to handle a situation when the application does an autofocus on an input and the user starts typing immediately. This is really nice, because this means that even if a user is not fully aware of this, it will still get added to the command chain.

Whenever you save your commands, your test is re-run. This gives you immediate feedback on your test flow. I have often found that my test is not really “repeatable” and I need to dive inside the code to handle this. That’s not always what I want, so to prevent automatic re-running of my test, I set "watchForFileChanges" to false in the cypress.json file.

One thing to keep in mind is that Cypress Studio does not record any assertions. Although you might be creating a great automation flow, you need to add some assertions to make your test really test something.

Cypress Studio builds on top of a Selector playground. This is another handy tool that helps you find the right selector in your application. It’s a great alternative to finding proper selectors via elements panel in Chrome developer tools.

What’s cool about Selector playground is that it has an API through which you can set up selector preference. The default preference can be found in docs, but if you wish to set up your own, you can do so by setting it up in your support/index.js file. For example, if you want to prefer using classes over any of the element attributes, you can set it up like this:

Who is Cypress Studio for?

To be completely honest, I wasn’t too excited when this feature was released. Trying to record my test flows will never be enough to generate a fully working test automation script. With a generated script you are just scratching the surface of what is happening in your app. There’s tons of network communication to be looked at and changes to be asserted.

But then I realized this was probably not built for someone who can already easily navigate themselves through Cypress or any other automation tool. It is actually a great learning tool for all those brave souls that want to start with test automation. And that’s where Cypress Studio becomes really empowering.

For years now, I held the opinion that Cypress is one of the greatest tools when it comes to starting with test automation. It has a really simple syntax and although you need to gather some JavaScript experience, you can get that thrill of your first running test very early on in your learning journey.

But even learning the basics of JavaScript might be too much in those beginnings. Especially when you are still learning what the web is made of. I started my first test automation efforts in Selenium IDE and there was a lot to figure out even with such a simple tool. Record and replay tools are great for getting that first time experience. Whenever you generate code, your natural next step is to examine how that code actually works. That can provide valuable insight.

E.g. you learn that for a normal user, typing into an input just a simple action. But for test automation script, it actually means:

1. selecting the element with proper selector
2. clearing the input
3. typing in the text
4. pressing an enter key

Not only that, but running a test multiple times introduces the problem of handling data that has been created, finding where the test should start and when should it end. This is just a fraction of things one needs to learn and it’s easy to forget these, once you’ve already passed a long way in your learning journey.

Cypress is a fairly new player in the test automation world and it seems to have gained a lot of love, and understandably, also some critique. Although the approach to testing might not sit well with everybody, there’s one area where the Cypress team pretty much nailed it. And that’s developer experience. With tools like Selector Playground and Cypress Studio, the Cypress team made sure that they open doors for everybody. At the time, when many make their first attempts in the tech world it makes perfect sense. Being one of those that started just a couple of years ago I really appreciate the effort to make test automation more accessible.

If you’ve enjoyed this post, visit my personal blog at filiphric.com, where I publish a new Cypress-related post every week.

The post Getting Started with Cypress Studio for Test Automation appeared first on Automated Visual Testing | Applitools.

On January 27, 2021, Angie Jones of Applitools hosted Brian Douglas, aka “bdougie”, Staff Developer Advocate at GitHub, for a webinar to help you jump into GitHub Actions. You can watch the entire webinar on YouTube. This blog post goes through the highlights for you.

Introductions

Angie Jones serves as Senior Director of Test Automation University and as Principal Developer Advocate at Applitools. She tweets at @techgirl1908, and her website is https://angiejones.tech.

Brian Douglas serves as the Staff Developer Advocate at GitHub. Insiders know him as the “Beyoncé of GitHub.” He blogs at https://bdougie.live, and tweets as @bdougieYO.

They ran their webinar as a question-and-answer session. Here are some of the key ideas covered.

What Are GitHub Actions?

Angie’s first question asked Brian to jump into GitHub Actions.

Brian explained that GitHub Actions is a feature you can use to automate actions in GitHub. GitHub Actions let you code event-driven automation inside GitHub. You build monitors for events, and when those events occur, they trigger workflows. 

If you’re already storing your code in GitHub, you can use GitHub Actions to automate anything you can access via webhook from GitHub. As a result, you can build and manage all the processes that matter to your code without leaving GitHub. 

Build Test Deploy

Next, Angie asked about Build, Test, Deploy as what she hears about most frequently when she hears about GitHub Actions.

Brian mentioned that the term, GitOps, describes the idea that a push to GitHub drives some kind of activity. A user adding a file should initiate other actions based on that file. External software vendors have built their own hooks to drive things like continuous integration with GitHub. GitHub Actions simplifies these integrations by using native code now built into GitHub.com.

Brian explained how GitHub Actions can launch a workflow. He gave the example that a team has created a JavaScript test in Jest. There’s an existing test using Jest – either npm test, or jest. With GitHub Action workflows, the development team can automate actions based on a starting action.  In this case, the operator can drive GitHub to execute the test based on uploading the JavaScript file.  

Get Back To What You Like To Do

Angie pointed out that this catchphrase, “Get back to what you like to do,” caught her attention. She spends lots of time in meetings and doing other tasks when she’d really just like to be coding. So, she asked Brian, how does that work?

Brian explained that, as teams grow, so much more of the work becomes coordination and orchestration. Leaders have to answer questions like:

• What should happen during a pull request? 
• How do we automate testing? 
• How do we manage our build processes

When engineers have to answer these questions with external products and processes, they stop coding. With GitHub Actions, Brian said, you can code your own workflow controls. You can ensure consistency by coding the actions yourself. And, by using GitHub Actions, you make the processes transparent for everyone on the team.

Do you want a process to call Applitools? That’s easy to set up. 

Brian explained that GitHub hosted a GitHub Actions Hackathon in late 2020. The team coded the controls for the submission process into the hackathon. You can still check it out at githubhackathon.com.

The entire submission process got automated to check for all the proper files being included in a submission. The code recognized completed submissions on the hackathon home page automatically.

Brian then gave the example of work he did on the GitHub Hacktoberfest in October. For the team working on the code, Brian developed a custom workflow that allowed any authenticated individual to sign up to address issues exposed in the Hackathon. Brian’s code latched onto existing authentication code to validate that individuals could participate in the process and assigned their identity to the issue. As the developer, Brain built the workflow for these tasks using GitHub Actions.

What can you automate? Informing your team when a user does a pull request. Send a tweet when the team releases a build. Any webhook in GitHub you can automate with GitHub Actions. For example, you can even automate the nag emails that get sent out when a pull request review does not complete within a specified time. 

Common Actions

Angie then asked about the most common actions that Brian sees users running.

Brian summarized by saying, basically, continuous integration (CI). The most common use is ensuring that tests get run against code as it gets checked in to ensure that test suites get applied. You can have tests run when you push code to a branch, push code to a release branch or do a release, or even when you do a pull request.

While test execution gets run most frequently, there are plenty of tasks that one can automate. Brian did something specific to assign gifts to team members who reviewed pull requests. He also used a cron job to automate a GitHub Action which opened up a global team issue each Sunday US, which happens to be Monday in Australia, and assigned all the team members to this issue. Each member needed to explain what they were working on. This way, the globally-distributed team could stay on top of their work together without a meeting that would occur at an awkward time for at least one group of team members.

Brian talked about people coming up with truly use cases – like someone linking IOT devices to webhooks in existing APIs using GitHub Actions. 

But the cool part of these actions is that most of them are open source and searchable. Anyone can inspect actions and, if they don’t like them, modify them. If a repo includes GitHub Actions, they’re searchable.

On github.dom/bdougie, you can see existing workflows that Brian has already put together.

Jump Into GitHub Actions – What Next?

I shared some of the basic ideas in Brian’s conversation with Angie. If you want to jump into GitHub Actions in more detail, you can check out the full webinar and the slides in Addie Ben Yehuda’s summary blog for the webinar. That blog also includes a number of Brian’s links, several of which I include here as well:

• https://bdougie.live/
• https://github.com/bdougie/live
• https://lab.github.com/githubtraining/devops-with-github-actions
• https://youtube.com/ilikerobot
• https://github.com/bdougie
• https://docs.github.com/en/actions/reference/events-that-trigger-workflows

Enjoy jumping into GitHub Actions!

Featured Photo by Aziz Acharki on Unsplash

The post Get a Jump Into GitHub Actions appeared first on Automated Visual Testing | Applitools.

Appium is an open source test automation framework for use with native, hybrid and mobile web apps.

Developers install Appium to drive iOS, Android, and Windows apps using the WebDriver protocol which gives you the ability to automate any mobile app from any language and any test framework.

Appium released its first major version almost 7 years ago. Since then, Appium has rolled out a lot of new features and its automation backend architecture has evolved quite a lot. 

That said, getting started with implementing automated tests and executing them using Appium the 1st time can be a daunting experience.

There are a lot of dependencies that need to be set up – node, android-command-line tools, appium, etc.

Appium Install Scripts

In order to make this task easier, and avoid having to do this manually, one at a time, I have written a script that will help setup the Appium-Android environment automatically for you. The script is available for Mac OSX and Ubuntu and will install the latest available version of the dependencies & appium itself.

You can find the scripts here:

MacOSX: setup_mac.sh

Ubuntu: setup_linux.sh

The mentioned setup scripts install all dependencies required for implementing / running tests on Android devices. To do the setup for iOS devices, run appium-doctor and see the list of dependencies that are missing, and install the same.

To ensure the setup is working properly, you can clone / download this sample repository (https://github.com/anandbagmar/AppiumJavaSample) which has 2 tests that can be executed to verify the setup. 

Refer to the README file for specifics of the prerequisites to do the setup and also for running the tests.

To get full value of your functional test automation, add the power of Visual AI to your tests. You can refer to the relevant tutorial for adding Applitools Visual AI to your Appium tests from here.

Summary

Automate your Android and Appium test execution environment installation using an automated script on MacOSX (setup_mac.sh) and Ubuntu (setup_linux.sh).

The post A Guide To Installing Appium -The Easy Way appeared first on Automated Visual Testing | Applitools.

Colleagues past and present suggested that I write a blog post about my tips and tricks in working from home. I’ve never considered myself an expert, but do have some systems in place that work for me.

I’ll begin with a statement – the last 4 weeks are not the normal work from home – there are a host of factors that further complicate the whole WFH experience.

1. Have a morning

Since starting at Applitools, I’ve been able to adjust my schedule and actually have been able to have a bit of a morning ritual and it’s been nice. I am sure to wake up 60-90 minutes before starting work, making it a point to take a breath, have a coffee, breakfast, and reach out to some of my family on the east coast.

2. Bandwidth and WiFi

Invest in the best ISP and speed that you can swing. I average about 330 Mbps down and 12 Mbps up – the upload speed bare minimum I’d recommend is 10Mbps, so I am hovering at the edge of acceptable here. The issue is for some reason in the US, there is a massive up-charge for upload bandwidth – it’s likely due to the fact that you are either using the network for business or running a small server farm, so ISPs take advantage of that. Since most of us connect wirelessly, I’d also suggest a good wireless mesh network, I’ve been happy with the Eero system. Basically, you never want to be the person with the bad connection or choppy video.

3. Be heard – loud and clear

Get a USB headset with microphone, wireless devices just do not work as good.

4. Bond with your colleagues

This may seem obvious, but having a personal relationship with your co-workers is the foundation of effective communication. Finding a point of common interest is a great way to start. Ask questions and learn about them – take it beyond work, but keep it work-appropriate.

5. Embrace your situation/environment

As a natural extension of bonding with your colleagues – don’t shy away from having your colleagues learn a little about you. For example – I usually do not shut the door to keep my cats out, I welcome them into my home office and enjoy when they make an appearance on a video share – however, be aware of where the line is and that they are not interfering with the task at hand or the level of professionalism needed for the call.

6. Share video

This one is easy – turn your camera on for meetings. Even if others are not sharing, I believe it’s nice to show your face and that your colleagues have your undivided attention. Also – hats are your friend and be aware of your hygiene and what is “in the frame” around you.

7. Over-communicate / collaborate.

When you work remotely, it’s important to be as clear as possible. Tools that help with effective collaboration should be leveraged, Slack and Asana come to mind for general purposes, but also seek task-specific tools that offer collaboration such as Applitools Slack integration or bug sharing features. Angie Jones just wrote a blog showcasing some of the great collaboration features in Applitools – check it out:  5 Visual Testing Features that Foster Collaboration Between Remote Workers

8. Lunch & Air

I am guilty of not always taking my own advice here, but when I do – I always feel so much better. Do your best to take a few minutes, enjoy lunch and even get out for a short walk to change the scenery and get some fresh air. Also, I am a coffee fanatic, but at home, do not drink coffee past 12pm as it could impact that night’s sleep.

9. Office space

If possible, have a dedicated office space. I realize this is a luxury in today’s situation, but if you will be working remotely – it’s helpful to put you into a work mindset and to be able to step away from that mind-set when your work day ends. For almost 2 years, I worked from and lived in a 650 sq ft home with my partner – there was no dedicated office, rather a desk in the kitchen / living room – I am not saying you cannot make it work, I am just saying it’s preferred to have dedicated space.

10. Set boundaries and stop working

I end my day routinely on-time – it’s a schedule and it works for me. There are always exceptions that require an altered schedule, but make sure they are just that, exceptions. Being able to step away, and have an evening routine such as workout, cooking a nice meal, having a glass of wine or all of the above will help ensure you return to work every morning, refreshed, recharged and firing on every cylinder.

For More Reading

• 5 Visual Testing Features that Foster Collaboration Between Remote Workers
• Overcome the challenges of Cross-Browser Testing using Applitools Ultrafast Grid!
• A/B Testing: Validating Multiple Variations
• Learn new skills on Test Automation University

The post 10 Essential Tips & Tricks on Working From Home appeared first on Automated Visual Testing | Applitools.