Podcasts about webdriver

What is a Sideways Test Pyramid in testing Have you seen the latest WebDriver.io feature that allows developers and teste to easily verify web page content and layout. What skill should you add to your tool kit after the recent announcement of 13billion dollars in this area? Find out in this episode of the Test Guild New Shows for the week of March 24 Time News Title Link 0:00 Register for LinkedIn NewsLetter https://links.testguild.com/wwA8x 0:36 TestResults.io  + TestGuild https://testguild.me/z36t2k 2:12 The sideways test pyramid https://testguild.me/qcnjxv 3:25 open source test automation project https://testguild.me/zaxxkz 4:25 Storybook 8 https://testguild.me/mz9qtz 5:35 WebDriver.IO Visual snapshot testing https://testguild.me/tyvscg 6:42 Learn Synthetic Monitoring Testing Webinar https://testguild.me/5ntk74 7:53 Puppet 2024 State of DevOps Report https://testguild.me/rjgq6w 8:29 Cleric AI SRE https://testguild.me/n5dstv 9:03 Follow the money 13 Billion  https://testguild.me/upwdg4

Are you ready for another dive deep into the world of test automation with industry heavyweight, Simon Stewart? In this enlightening session on the Test Automation Experience, our host Nikolay Advolodkin, welcomes back the esteemed guest to tackle the nuances of quality assurance in modern software development.Simon discusses important topics ranging from the challenges of turning prototypes into production-ready solutions to revelatory discussions on Selenium 4's new features, including the nifty remote WebDriver builder. He candidly shares his insights into Google and Facebook's unique approaches to testing and continuous deployment, underlining the significance of testing culture over rigid roles.Through anecdotes and advice, this episode is not just a treasure chest of testing strategies but also a call to enjoyment and balance in the professional journey. Tune into to join Simon and Nikolay as they traverse the intricate web of automated testing!CONNECT WITH SIMON STEWART

Welcome to Test Automation Experience with Nikolay Advolodkin!In this week's episode, Nikolay Advolodkin, Principal Developer Advocate at Sauce Labs, and Christian Bromann, Creator of WebDriverIO, host a hands-on live coding workshop that delves into the world of Sauce Labs and WebDriverIO. Join us as we walk through solving testing exercises on WebDriverIO and Sauce Labs in a live environment. Don't miss out on the chance to gain practical insights into live testing with JavaScript!Subscribe now and stay ahead of the curve.CONNECT WITH CHRISTIAN BROMANN

In this episode, you'll hear from five SeleniumConf Chicago 2023 speakers and/or project core committers about their upcoming talks, the reasons for their participation, and the benefits attendees can expect to gain from the conference. Additionally, our guests shed light on the Webdriver ecosystem - open-source projects that complement and add features and functionality to the browser automation capabilities that Selenium provides. They discuss the inaccuracies and misleading comparisons that pit Selenium against tools such as Cypress and Playwright. They also explain how using Selenium with Webdriver frameworks can help achieve parity with these tools while using real browsers. Join us as we hear from Corina Pip, QA Lead at Deloitte Digital; David Burns, Head of Open Source Program Office at BrowserStack; Noemi Ferrara, Software Dev Engineer II-TEST at Amazon Spain; Simon Stewart, Selenium Project Core Contributor and creator of WebDriver, and Marcus Merrell Vice President of Technology Strategy for Sauce Labs, . Tune in to learn more about browser automation, the Webdriver ecosystem, and how the community can work together to achieve better results.

Want to quickly see a free way to add AI to your Selenium, Cypress, or WebDriver.io automation tests? In this episode, Chris Navride, founder of Dev-Tools.AI, shares how to write tests with visual AI using their open-source library that extends existing test frameworks. Discover how to integrate with your framework, find elements without digging through the page source, teach the bot, and much more.

¿Queréis saber que es el dominio mental, para qué sirve y cómo se controlan las poblaciones? Hablaremos con el coronel Pedro Baños sobre su nuevo libro "El dominio mental " (Ariel). Trataremos también un extraño caso acontecido en youtube. No os lo perdáis. ¡Comparte y síguenos! Escucha el episodio completo en la app de iVoox, o descubre todo el catálogo de iVoox Originals

FeaturingEve Porcello — Twitter, Website, GitHubAdam Banks — Twitter, Website, GitHubchantastic — Twitter, Website, GitHubLinksLearning React, 2nd EditionMoon Highway - professional web development trainings30 Day Free Trial for O’ReillyGraphQL is for Everyone monthly webinarsSponsorsInfinite RedIn over your head with a React or React Native app? Infinite Red can help.They are React Native core contributors who've been designing, building and shipping apps for over 10 years. Head to reactpodcast.infinite.red to learn more.TestCafeA node.js tool to automate end-to-end web testing.Write tests in JS or TypeScript.TestCafe works with all popular OS & browsers and takes 1 minute to setup: no WebDriver or other tools required.It's free, open source, and will help you enjoy writing end-to-end tests.Visit testcafe.io to automate your code testing — free!Black Lives MatterPlease join us in donating to the Equal Justice Initiative

FeaturingChris on Code — Twitter, Website, GitHubchantastic — Twitter, Website, GitHubLinksMakeReactApps.com — Build real-world React projectsWes BosReact HooksScreenFlowDreamweaverNicholas Cerminara, scotch.io co-founderJamstackjwt — JSON Web TokenBuySellAds100: The Business of Remix with Ryan Florence and Michael JacksonRedwoodjsAirtableNotionTypeScriptVisual Studio CodeSponsorsInfinite RedIn over your head with a React or React Native app? Infinite Red can help.They are React Native core contributors who've been designing, building and shipping apps for over 10 years. Head to reactpodcast.infinite.red to learn more.TestCafeA node.js tool to automate end-to-end web testing.Write tests in JS or TypeScript.TestCafe works with all popular OS & browsers and takes 1 minute to setup: no WebDriver or other tools required.It's free, open source, and will help you enjoy writing end-to-end tests.Visit testcafe.io to automate your code testing — free!Black Lives MatterPlease join us in donating to the Equal Justice Initiative

WebDriver joins us to chat about small gang wormhole plays including baiting explorer killing tech 3s and the Nomadic lifestyle. Discord ServerPatreonWebdrivers BRNoir. Academy is recruiting!!!!5v5 EvE Scrims Discord

We are going to learn about, How To Explain Test Automation Framework To The Interviewer. No matter if you are explaining the Framework in your Telephonic interview or in person, You can use this mind map to explain in a simple manner. I have discussed two-Test Automation Framework in Java, TestNG selenium and Webdriver, ReportNG, POM, POI lib, Maven Project https://scrolltest.com/2019/12/05/explain-test-automation-framework/ Download Test Automation Framework # 1: Here Download Test Automation Framework # 2: Here Mind Map : Here --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app

In gesprek met Job van den Berg over het JOSF Selenium framework. Het verschil tussen Selenium IDE en Selenium Webdriver. Mobile testing met Appium en JOSF voor low-code platformen zoals Pega.

This episode of Views on Vue features Tracey Holinka, a web application architect with the role of front-end lead for Bloomberg industry group. The Views on Vue podcaster begin by asking Tracey how she got into Vue. Her Vue experience starts at work where she didn’t like the technologies they were using so she and a colleague decided to switch over to GraphQL, Apollo Client, and Vue. One of the many things that she appreciates about Vue is its diverse array of applications.   Ari begins a discussion on Vue and CSS by asking Tracey if she has found any notable differences, in terms of developer experience, between doing single file components or using Vue by including a script tag. Tracey responds to this by sharing her preference for single file components because she appreciates the division of the languages, or in other words she likes HTML files only having HTML, her CSS files only having CSS, and so on. She feels that with this separation of languages she can work faster and understand the code easier.   The Views on Vue panelists then ask Tracey how she handles CSS in her Vue development environment. She shares her opinion on how she used to prefer manual scoping, particularly for smaller projects and push CSS modules for larger projects. She then goes on to share why she now prefers CSS modules for projects of all sizes. She then goes on to share some of her best practices with the other Vue developers for writing proper CSS including ways to prevent collisions and when she uses CSS preprocessor. The panelists then asked Tracey how she knows when to modularize or componentize an element of a page or other functionality. In response to this question Tracey shares how she came up with her best practices and why she likes to componentize when she does.   Next the Vue experts discuss tools they use to help support the use of component libraries and ways to help other developers figure out what components are available. Tracey shares how she went to a Vue conference and heard about the component library Storybook as well as storyshot which is a plugin for Storybook that is used in regression testing. Storyshot works by taking an image of a component and uses it to check the CSS of a page. Since Tracy had been using Vue for about a year before using Storybook and storyshot, Ari asks how difficult it is to retroactively fit an application with these tools. Tracey shares that this retrofitting is easy, particularly more so if the user is familiar with unit testing already. The Vue experts also discuss different technologies that they use for unit testing such as Jest, Vue Util, Cucumber, and Webdriver.io. They discuss the benefits of using GraphQL and Apollo instead of the more common Rest API solution.   The final topics discussed by the Vue panelists are community building and women in the technology community. Tracey’s shares her observation that the Vue community is growing but she wants to focus on having more women involved. The panel holds a discussion about women in tech and some of the challenges facing them. They discuss some of the support that is out there for women to help them succeed in technology. The Vue community is a very inclusive community that is proactive about including everybody.  

This episode of Views on Vue features Tracey Holinka, a web application architect with the role of front-end lead for Bloomberg industry group. The Views on Vue podcaster begin by asking Tracey how she got into Vue. Her Vue experience starts at work where she didn’t like the technologies they were using so she and a colleague decided to switch over to GraphQL, Apollo Client, and Vue. One of the many things that she appreciates about Vue is its diverse array of applications.   Ari begins a discussion on Vue and CSS by asking Tracey if she has found any notable differences, in terms of developer experience, between doing single file components or using Vue by including a script tag. Tracey responds to this by sharing her preference for single file components because she appreciates the division of the languages, or in other words she likes HTML files only having HTML, her CSS files only having CSS, and so on. She feels that with this separation of languages she can work faster and understand the code easier.   The Views on Vue panelists then ask Tracey how she handles CSS in her Vue development environment. She shares her opinion on how she used to prefer manual scoping, particularly for smaller projects and push CSS modules for larger projects. She then goes on to share why she now prefers CSS modules for projects of all sizes. She then goes on to share some of her best practices with the other Vue developers for writing proper CSS including ways to prevent collisions and when she uses CSS preprocessor. The panelists then asked Tracey how she knows when to modularize or componentize an element of a page or other functionality. In response to this question Tracey shares how she came up with her best practices and why she likes to componentize when she does.   Next the Vue experts discuss tools they use to help support the use of component libraries and ways to help other developers figure out what components are available. Tracey shares how she went to a Vue conference and heard about the component library Storybook as well as storyshot which is a plugin for Storybook that is used in regression testing. Storyshot works by taking an image of a component and uses it to check the CSS of a page. Since Tracy had been using Vue for about a year before using Storybook and storyshot, Ari asks how difficult it is to retroactively fit an application with these tools. Tracey shares that this retrofitting is easy, particularly more so if the user is familiar with unit testing already. The Vue experts also discuss different technologies that they use for unit testing such as Jest, Vue Util, Cucumber, and Webdriver.io. They discuss the benefits of using GraphQL and Apollo instead of the more common Rest API solution.   The final topics discussed by the Vue panelists are community building and women in the technology community. Tracey’s shares her observation that the Vue community is growing but she wants to focus on having more women involved. The panel holds a discussion about women in tech and some of the challenges facing them. They discuss some of the support that is out there for women to help them succeed in technology. The Vue community is a very inclusive community that is proactive about including everybody.  

Today we’ll be test talking with Kwo Ding all about his new Sonar WebDriver Plugin which is a static code analysis tool that helps you to follow best practices for writing WebDriver tests. If you're interested in writing clean Selenium code, you don’t want to miss this episode.

Today we’ll be Test Talking with Casey Cantwell a Senior QA Architect about WebDriver.io Automation. This episode came about after I received an email from Casey who asked “In reading your blog post on “frameworks you need to know article” I was surprised to see a framework based on Node.js didn’t get any love in your article. We chose Webdriver.IO as our product is all Node.js / JavaScript and are loving it.” So I asked Casey if he would be open to being interviewed about his experiences with creating Node.js based automation frameworks. So that what will be test talking all about today.

Interview with Andy Knight, the Automation Panda. * Selenium & WebDriver * Headless Chrome * Gherkin * BDD * Given When Then * pytest-bdd * PyCharm * Writing Good Gherkin * Overhead of Gherkin and if it's worth it * When to use pytest vs pytest-bdd * The art of test automation Special Guest: Andy Knight.

Podcast Description Marcus is a Staff QA Engineer at RetailMeNot, inc. He has been in QA-related jobs since 2001, having used WebDriver since its debut in 2008. Marcus is also the co-chair of the Selenium Conference Planning Committee. He's an avid piano player, plays bass for the RetailMeNot house band the WailSharks, and enjoys life in Austin, TX with his wife and two crazy boys. Additional Resources The Ministry of Testing PodcastSelenium ConferenceSelenium Project Twitter Marcus Merrell Become a #causeascene Podcast sponsor because disruption and innovation are products of individuals who take bold steps in order to shift the collective and challenge the status quo.Learn more >All music for the #causeascene podcast is composed and produced by Chaos, Chao Pack, and Listen on SoundCloud. Listen to more great #causeascene podcasts full podcast list >

Guests Brian Mann and Gleb Bahmutov join our hosts to discuss Cypress, and open source test runner that's built for the modern web. With fast, easy and reliable testing for anything that runs in a browser, the show discusses how cypress utilizes the platform and the ease of use for end developers. Visit the website for This Week in Web, resources & more: https://thewebplatformpodcast.com/164-cypressio   Follow The Web Platform podcast on Twitter for regular updates @TheWebPlatform.

Derek is joined by coworker Sean Doyle and Codecademy's Alex Clark to discuss the process of test-driven development and the development of a new TDD course for Codecademy. Testing Rails Four-Phase Test Test-Driven Development Course on Codecademy Red-Green-Refactor Chai WebdriverIO - WebDriver bindings for Node.js SuperTest - Super-agent driven library for testing node.js HTTP servers using a fluent API

Chris and Ed do an extremely rare daytime recording of the show on the American Memorial Day holiday. But why is a Canadian not working on an American Holiday? You’ll have to tune in to find out why along with some thoughts on mentoring and why the current crop of browser-centric testing tools are completely shit. Thanks to Ben Ramsey for his poetry choice and Chance Garcia for allowing us to bring another health issue to people’s attention. Do these things! Support us via our Patreon Buy stickers at devhell.info/shop Follow us on Twitter here Rate us on iTunes here Listen Download now (MP3) Links and Notes Please support Ed’s efforts to make OSMI his main gig! Both Chris and Ed will be at CakeFest 2017 WebDriver is an API in heavy use at Mozilla (and elsewhere) for doing browser automation work Ed talked about a testing tool called Fake from his webOS development days that promoted a very different testing paradigm Chris has done browser automation in PHP using Behat, Mink and a lot of swearing Most current browser-centric UI testing tools are Rube Goldberg machines Great blog post from the ClojureScript community showing off property-based testing and immutibility Also some great work being done in PHPUnit with snapshot testing

After the cliffhanger left in Episode 62: UI for U and I, we follow up with a short discussion about how we specifically do UI Testing at The Frontside in Austin, Texas. Resources: Tweet that led to this discussion Unit Testing Acceptance Testing Ember CLI Mirage Percy Test-Driven Development Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode #68. My name is Charles Lowell. I'm a developer here at The Frontside and podcast host-in-training. I'm here today with Jeffrey and Elrick, two other developers here at The Frontside. We are going to carry on where we left off back in Episode 62. There was an implicit promise to talk about the way that we do UI testing. JEFFREY: We had a cliffhanger. CHARLES: Yeah, we did. It ended with a cliffhanger and someone actually called us on it, which I hate it because they're making more work for you. But Ian Dickinson from Twitter writes, "Hey, you guys promised to talk about how you do UI testing at The Frontside but never actually delivered on that promise." We're going to try and make good on that today. JEFFREY: We like to resolve our promises. CHARLES: Oh! [Laughter] CHARLES: You've been on vacation for a week, Jeffrey and I forgot what it was like to have you in the office. JEFFREY: Not enough code puns. CHARLES: Oh, code pun. There you go. It's like CodePen except all of the code has to make puns. I like it. Internet is awash with people bloviating about testing so we figured we'd take our turn at it. We promise to keep it short. We'll keep it focused but it seems like a value that we do have so might as well talk about it a little bit. You guys ready? JEFFREY: Let's talk about testing. CHARLES: I think one of the best things to do is to use something concrete, not just to talk about abstractions, not just to talk about things that might be but we're actually starting a project here in three days. It's going to kick off on Monday and testing is going to be a key part of that. Why don't we talk a little bit about what it's going to look like as we kind of lay the groundwork for that project? JEFFREY: As we start this project, the very minimum baseline that we want to get immediately is acceptance tests in the browser. We want to make sure that when you fire up this app, it renders, you get the fallbacks for the basic functionality of this app immediately. As we're building features on top of this app, that's when we bring in unit tests, as we say, "We're building this new component. We're building this new feature. That's part of this app. We're going to use test driven development and unit tests to drive the creation of that," but ultimately, our test of quality for that app and our assurance of quality over the long term comes from the acceptance testing. CHARLES: People often ask the question, "When is it appropriate to write those unit tests? When is it appropriate to write those acceptance tests and how much time so I spend doing each one?" Personally, when I was starting out with testing many, many, many years ago, I really, really like unit tests and I like developing my code based around unit tests. The thing that I liked about them was that they were fast. The entire test suite ran in a matter of seconds or minutes. JEFFREY: And you get coverage. CHARLES: Yes. JEFFREY: Like you get your coverage numbers up. It is like every line that I wrote here has some kind of code coverage. CHARLES: Right and it feels really good. I also think that unit tests really are great for mapping out the functionality in the sense of getting an intuitive feel of what it's like to use a unit before it's actually written. You get the experience like, "This is actually a terrible API because I can't write the test for it," so obviously it's not flexible and it's really mungy so I really, really enjoyed that. The thing that I hated most is acceptance tests. They're hard to write. They were slow to run and it seemed like when they would break, it was not always clear why. JEFFREY: Wait, so we were just singing the praises of unit tests. What's wrong with them? CHARLES: Part of it is kind of the way that you conceive of a test: what are you actually doing? I think if you think of tests not so much as something that's there for regression or something that's there to drive your design, both of which are very, very important things but more is just kind of measurement: taking a data point, what is it that I want to measure? In the case of a unit test, I want to measure that this library call does exactly what I think it's going to do so I can take that data point, I can put it on my spreadsheet and I can say, "I got that base covered." The thing is that an acceptance test just measures a completely separate thing and by acceptance test, we're talking about testing as much of the stack your entire integrated application as you can. Oh, boy. Don't get me started on terminology but when you have an acceptance test, what you're measuring is, "Does my application actually function when all the pieces are integrated?" So you're just like a scientist in the laboratory and you're making an observation and you're writing it in your notebook. Yes or no, does it work? In the same way that you're taking a perception when your eye perceived the photon of light, you can say, "That thing is there," when it bounces off the chair in the room, I know that the chair is there. If what you want to measure, what you want to perceive does in fact my application work for user, then an acceptance test is the only thing that will actually take that measurement. It will actually let you write that data point down in your notebook and move on. I think that the problem with unit tests... Well, there's nothing wrong with them, it's just they don't observe your integrated application so that means you're blind. It's only part of the story so that's why we find that acceptance test really are like the highest value tests, even though they suck to write and even though they take a long time and even though when they break. Sometimes, they break at some weird integration point that you didn't see and that's really hard to diagnose. But you know what? That same integration point, that's a potential failure in your app and it's going to be just as weird and just is esoteric to track down. That's my take on it. One of the things that you're describing, Jeffrey is we set up those acceptance tests suites, why do we set them up? What, because they're part of like a process? JEFFREY: Yeah, that process is that we start at the very beginning when our project on the very first day is when we like to set up continuous integration and make sure the repos all set up, make sure the deployment pipeline is set up. CHARLES: What do you mean by deployment pipeline? JEFFREY: The deployment pipeline looks like, "We've got our a good repo and our version control under consideration and from there, anytime there's a push to the master build, any time a pull request gets accepted, we build out an continuous integration server, whether that be Travis or Circle or any of the solutions out there. We want to run that entire suite of acceptance tests and whatever unit tests we have, every time we have a push of code to past a person's local box. CHARLES: Right, a push to master is tantamount to a push to production. JEFFREY: Yes, that is the ideal. Any time that the code has been validated that far, yes this is ready to go to production and our acceptance test suite validates that we feel good about this going out. CHARLES: Yeah so the thing is if all you have is unit tests, you have no way of perceiving whether your application will actually work in a real browser, with real DOM events talking to a real server, do you really want to push to production? [Laughter] JEFFREY: We had some client work recently. We do have a lot of acceptance tests coverage and actually a lot of unit tests too. We changed the browser running on the CI server from Chrome 54 to 58 and uncovered a lot of bugs that acceptance tests coverage found, that unit tests just would never have revealed that the end user had a problem. CHARLES: Now, why is that? Let's take it down a layer now, when we do an acceptance test, what does that actually mean? What are we describing in terms of a web application? JEFFREY: We're describing that we have an application that we're actually running in a real browser. Usually, you're going to have to have some kind of stubbed out things for authentication to make sure you can get around those real user problems but you're actually running the real application in a real browser, not in a headless browser but an actual browser with a visible DOM. CHARLES: Yeah, not a simulated DOM. JEFFREY: Exactly so you can surface the kinds of real problems that your customer will actually have. CHARLES: In terms of interaction, you are not sending JavaScript actions. JEFFREY: No, you're firing DOM events. You're saying, "Click this button," or, "Put this text into this input," and the underlying JavaScript should be pretty opaque to you. You shouldn't be calling directly at JavaScript events in any acceptance tests. You want to rely on solely what's on the DOM. CHARLES: Yeah. I would say the ideal set up with an acceptance test, you should be able to have your acceptance tests suite run and then completely and totally rewrite your application, let's say rewrite it from Ember to Angular or something like that and you don't have to change your acceptance tests suite at all. JEFFREY: Yeah, usually the only binding you have is IDEs or classes or whatever you're using to select elements and that should be it. CHARLES: Right, you're interacting with the DOM and that's it, so now in terms of the server, most modern web apps -- in fact, all of them -- certainly in the kind of swimming pools in which we splash, have a very, very heavy server component. There's a lot of requests. Just even load the page and then throughout the life of the page, it's one big chatterbox with the server, what do we do there? JEFFREY: That's when we need to pull on a tool that can mock a request for us, the one that we fall back on a lot is Ember CLI Mirage that is built on top of Pretender. It's a really nice way to run a fake server, basically. I would even take that a step further and would love for the tool to be another server completely that's running on your local box or your CI box or whatever so that you get the full debugging available in developer tools and you actually see those requests as if they were real ones that just coming from a fake server. CHARLES: Right, as Jeffrey said right now, we use a tool called Mirage, which for our listeners in the Ember community, they know exactly what we're talking about. It's the gold standard. What it does is it actually stubs out XML HTTP request, which is what most of the network traffic in your browser after the initial load is encoded in. It's got a factory API for generating high quality stub data so your code is actually making a [inaudible] request and it's all working. Unfortunately because it's stub, as you said none of the developer tools work. But there's been talk about making Mirage, you service workers so that you would have all of that running. You could still run Mirage inside your browser. It would be a different process. I think the server's workers run off thread. That actually is very exciting. It's a great tool. I think it's a great segue to talk about one of the things that we love. This is absolutely a mandatory requirement for us, when we start a project is to have acceptance testing in place. Back in the battle days, it would take us, I want to say like two weeks just to set up our acceptance tests suite for a project. This is when we were doing Backbone and this is when we were doing the early, early days of Ember. We would start a project, we'd spend all of that time upfront just so that we could have an acceptance testing framework and that was actually a really hard sell because it's like, "What are you doing? You don't have anything to show," and it's like, "Well, we're actually setting up an app-a-scope," so that we can observe your application and make sure that it's running. The very first thing that we do is we set up an app-a-scope and it's like, "Nobody sets up an app-a-scope," so they can actually see their application. But one of the great things that has happened and one of the reasons we love Ember so much is that you actually get this now pretty much for free. I think there's still some stuff that's very white box about Ember testing and a lot of times, we talked about that ideal of you should be able to swap out your entire implementation of your app but your acceptance test suite stays the same. That's not quite possible in Ember. You have to know about things like the run loop and it kind of creeps its way in. But it's 95% of the way there. It's mostly there. It's good enough. It's better than good enough. It's great. You just get that for free when you start a new Ember project. JEFFREY: We've talked a lot about the Ember ecosystem and what we like there about testing and we're going to be doing some React work soon. What's the story there? CHARLES: Well, I'm glad you asked, Jeffrey. Yes, we're going to be doing some React work soon so again, this is a new project and it's absolutely a 100% ironclad requirement that we're not going to develop applications without an app-a-scope but I think that the React community is in a place where you kind of have to build your own app-a-scope. You know, actually having kind of scoured the blogosphere, there are a lot of people in the React community who care very deeply about acceptance testing but it does not seem like yet a mainstream concern or a mainstream pathway. For example, Jest which is the tool that is very, very popular in the React community and I was actually really excited about reading the documentation. It doesn't even run in the browser. It's Node.js only, which for us is it's a nonstarter. That makes it really fast but it actually is not an app-a-scope which is what we need. It does not lead us to actually observe our application. It lets you observe the components from which your application is built but actually you're blind to what your application actually looks like in production. I was kind of bummed about that because I know that there is work and I know that the maintainers of Jest carry very deeply about making it run in the browser eventually. There are some experimental pull requests in the couple branches. Who knows? Maybe those are even merged right now but the point is, it's still very early days in there. There are a couple of people who have used like Nightmare that they've booted up and they're kind of controlling the running acceptance tests in Nightmare from Jest. Now, that sounds great but part of your app-a-scope needs to perceive different browsers. In fact, users don't use Nightmare.js. They use Chrome, they use Mobile Safari, they use Firefox and normal Safari and Edge and what have you. There's actually a great set of tool. Testem and Karma are all set up to be able to run all these browsers and have those browsers connect to your test suite and run them in parallel. Again, that's kind of a bar. That's what we're actually working towards right now. We're running some experiments to try and use Mirage and Karma with Mocha to actually get the multiplicity of browsers, actually using browsers, be able to use real DOM events and test a real API or as real as API as we can get. I'm kind of excited about that work. I hope that the acceptance testing story gets a lot better in the React community and it's early days but like I said, we care very deeply about it. I know a lot of other people care very deeply about it. Some people have some different feel like it's not necessary. Some people feel like they don't need an app-a-scope. They're like, "You know what? My application is there and I know it. I don't actually want to look at my application but I know it's there." I think that's actually the pervasive model at Facebook and obviously, they're doing something right over there. Although, who knows? I'll keep my mouth shut. No, but seriously, there's some good software that comes out of there. The Facebook application itself is pretty simple. Maybe it's enough to perceive your components and not have to perceive your application as a whole. Or there are other ways that you can go about it. If you've got lots and lots of money, you can have people do it and they do a pretty good job. I understand that's another strategy. In fact, I think that's what Facebook does. I've read a lot of the debates between why they go with unit tests, why they don't go with acceptance tests? They've got a QA Team. They probably has their own tools or who knows? Maybe they use like Capybara or WebDriver or Selenium and those tools are really, really excellent and they are truly, truly black box tools. JEFFREY: Elrick, you brought up an interesting new angle that I think is starting to come of age that I think as an awesome addition to the toolkit which is visual regression testing. How far that's come in the past couple years and how valuable that is for getting the CSS confidence. Unit test coverage is great for testing your individual components, for testing JavaScript functionality but ultimately, the confidence around CSS comes from visual regression testing. That's the only way you can get that and I think that's helping the CSS ecosystem to be a little healthier to encourage better practices there and having engineers who are more averse in JavaScript and not as averse in CSS, feel more comfortable making CSS changes because they have that type of testing to them. ELRICK: When you're doing things programmatically, you wouldn't really know what's going on visually unless you physically go and check it and then that may not be the best solution because it takes a lot of time. JEFFREY: Yeah. CHARLES: The tool that we have that have the most direct hands on experience with is Percy and I think, you guys have more experience with it than I do but it's very intriguing. When I heard about this I was like, "How does this even work?" JEFFREY: It's so great to have visual diffs. As it runs through your acceptance test suite, you specify, "Take a screenshot now," so you can compare against what came before. Sometimes you run into some finicky things that are like, "I have some data that's not completely locked in." One of the most common dis I get is, "Hey, there's deep change in the screenshot from acceptance tests." I'm like, "Oh, because I've hard code that date. Always do the same," but it's great at servicing and like, "This button move 10 pixels. Did you intend to do that?" In particular, when we upgraded a component style guide library, we noticed a lot of changes that came out of that. Actually they were okay changes but it was important to know that those has changed. CHARLES: Right and there were actually some visual regressions too. I remember there was some button turned red or something like that and it's like, "Oops, something got screwed up in the cascade," which always seems to happen. JEFFREY: I think it has caught some bug before and some changes we've made to select component and like, "This has the same functionality," but actually the classes around this particular component changed. "It doesn't look the same. What happened?" It's been a really valuable tool. CHARLES: The acceptance test from the code perspective actually completely and totally worked, right? JEFFREY: Yes. Exactly. CHARLES: But, yeah, acceptance test didn't catch it because they were not perceiving the actual visual style of the application. It's an enhancement or an add-on to your app-a-scope so that it can see more things and you can perceive more things. I love it. When you have an acceptance test suite, then it allows you to do those power add-ons because you're actually loading up your whole application in a real browser, in a real DOM and you're making it go through the paces that an actual user will do so you can do things like take visual diffs. If you're just doing unit tests in a simulated DOM, that's just not a possibility because you're not actually running the painting algorithms. Whereas, an acceptance test, you are so it allows you to perceive more things and therefore, check for more things and catch for more things. JEFFREY: I think my next area of exploration that I'm interested in is, let's say you have a web app with sound effects. Is there something to validate the sound effects? Or take a video capture of your app because that would be really cool. I'm sure there's something out there but I think I'll be my [inaudible] to go find out. CHARLES: And then we actually touched on this on the episode on accessibility, you can test your accessible APIs when you're running acceptance test. Another thing that I might add is as terms of regression testing, acceptance tests have a much longer term payoff because I feel very strongly about test driven development for your unit tests. I think unit tests are really, really great and if you're building tiny units, especially novel ones that you haven't really built before, they're not cookie cutter things like a component or something like that. It's some unique service or just a utility library or some bundle of functions. Using test to drive those out is extremely important. But I almost feel like once you've done that, you can throw those tests away. By all means, they're free to keep them around but your tests also serve as a fence, a wall, a kind of exoskeleton for code and that can be great except when you want to change and refactor the code around, you have to tear down the wall and you have to break the exoskeleton of the code. If your code is siloed into all these tiny little exoskeletons, elsewhere it's going to be very hard to move and refactor or it's going to be hard to do without rearranging those walls. I guess my point is, with an acceptance test, you're making that wall very big. It covers a lot of area so you can have relative freedom to change things internally and rapidly. While the acceptance test is slow, the speed for internal change that engenders, I think is worth it. I think that's another pay off because I think that tests do have a shelf life and I think that the shelf life for unit tests is very small. Whereas for application level tests, it's very large. Then I guess, the final thing is really, there's no such thing as acceptance tests and integration tests and unit tests and blah-blah-blah-blah-blah, all the different types of tests. It really is just a matter of scope. It's like how big are the lines that you're drawing so acceptance test is a type of test that we give a name for tests that have a very high amount of scope. They cover a lot, where in unit tests, have a very small scope but there's a whole spectrum for every piece of code that is running in between, there's a whole spectrum in between. All righty. Well, this concludes Episode 68 of The Frontside Podcast. I told you it was going to be a short one but I think it's going to be a good one. I know that this is a subject that's very, very near and dear to our hearts. We don't dedicate explicit time to it all that often but I'm sure we will return to it again in the future. Jeffrey, Elrick, thank you guys for joining us for this discussion and we're out.

За JavaScript поговорили обстоятельно, немного поспорили и даже не уложились в 2 часа. Местами хардкорно, местами может быть и поверхностно - эксперты приглашаются поправлять нас там, где мы были неправы. Гости выпуска: Яков Крамеренко (Киев) - языковой полиглот, специалист в автоматизации тестирования. Последние месяцы серьёзно взялся за JavaScript, руки уже все в бинтах, а на лбу колея от граблей. Юрий Дымов (сделан в Китае) - Архитектор в SAP China. Считает JavaScript хорошим языком, и не краснеет. Юрий занимался тестированием на JS всерьёзку, и нам за всё ответит. Виктор Зозуляк (Краков) - контрибьютер в Angular, любит protractor, но странною любовью. Алексей Виноградов (Дормаген) - просто рад возможности посидеть с умными людьми. Темы выпуска: Что такое JavaScript и чем он не Java (интерпретация, компиляция) Необычные свойства Javascript (однопоточность, асинхронность) Стандарты и “компилируемые в js” языки ES5 ES6 ~ ES7 TypeScript Flow Babel list of languages that compile to javascript IDE WebStorm/IntelliJ IDEA Enterprize Atom Sublime Visual Studio Code Сравнение скорости редакторов (в плане задержек при наборе кода): Server-Side JS vs Frontend JS Зачем тестировать на JavaScript Известные фреймворки (Jasmine, Mocha, Chai, etc.) их особенности https://habrahabr.ru/post/314978/ Веб-тестирование на JavaScript. Зачем? WebdriverJS, Webdriver.io, Protractor, Nightwatch.js, Angular Protractor for Angular applications Protractor for Angular-like applications :) Protractor for non-Angular applications Selenium-webdriver Проблемы Наши промисы - говно, надо бы всё поменять С новыми модными методами тоже хреново работает Неплохой доклад о современном webdriverjs based тестировании, о тех проблемах что были, и что делать что бы с ними бороться… API тестирование на JavaScript. Зачем?

There is a YouTube Channel that has uploaded more than 1.5 million videos since 2013. There are no people, landscapes, or animals in any of the videos. Only red and blue rectangular shapes with random tones playing in the background. Who is behind this notorious account and what are the videos hiding? To watch one of the Webdriver Torso videos and to get more information about the YouTube account please visit CloudedMysteries.com Please follow us on Twitter @clodedpodcast.com Music in this episode provided by: "Creepy" and "Piano Moment" - Royalty Free Music From Bensound "Crypto" - Kevin MacLeod(incompetech.com) Licensed underCreative Commons: By Attribution 3.0 http://creativecommons.org/licenses/by/3.0/ “A HumanBeing” by Andy G. Cohen Released under Creative Commons Attribution International License https://andyg.co/hen/songs/human "When YouLeave" By Sergey Cheremisinov "Sinister Calamity" By Dark Asylum Music --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app --- Send in a voice message: https://anchor.fm/clouded/message Support this podcast: https://anchor.fm/clouded/support

Třináctá epizoda se věnuje novinkám kolem Xboxu, změnám v .NETových projektech, Microsoft Azure atakdále… Odkazy: Microsoft na E3 Letní update Xbox One Červnový update Xbox One UWP Změny v project.json Azure Security Site Azure DevTest Labs GA ADAL .NET v3 MS WebDriver Část Edge WebGL je open-source SQL Server Management Studio 2016 Prodloužení AI pro […]

01:20 - Julie Ralph Introduction Twitter GitHub Google (Seattle Office) Angular Team Protractor 02:47 - Finding Angular and the Team 04:50 - End-to-End Testing WebDriver 08:46 - Making Scripting Easier with Protractor 10:57 - Grabbing By Model 11:27 - Framework Support Jasmine Mocha Cucumber 12:59 - What You Need to Know to Work with Protractor Node.js Debugging Knowledge 14:14 - Data Hydration for Tests 16:10 - Using Mock Modules 17:52 - When Should People Start Using Protractor? 23:21 - Using Protractor for Performance Testing benchpress 25:06 - Writing End-to-End Tests 29:28 - Testing Stories The PageObject Pattern [YouTube] Jim Lavin: Using Page Objects in AngularJS Protractor Authentication User Scripts Red Flag: Logic in Your End-to-End Tests 32:05 - Protractor 2.0?! 33:33 - Support for Angular 2   See Also [YouTube] Julie Ralph: End to End Angular Testing with Protractor ​ Picks bardjs (John) [Pluralsight] Play by Play: John Papa and Ward Bell (John) The revolution that could change the way your child is taught (Ward) Teach Like a Champion: 49 Techniques that Put Students on the Path to College (K-12) by Doug Lemov (Ward) Colt Express (Joe) ng-book (Chuck) DevTools: State Of The Union 2015 by Addy Osmani (Julie) Digital Spring Cleaning (Julie)  

01:20 - Julie Ralph Introduction Twitter GitHub Google (Seattle Office) Angular Team Protractor 02:47 - Finding Angular and the Team 04:50 - End-to-End Testing WebDriver 08:46 - Making Scripting Easier with Protractor 10:57 - Grabbing By Model 11:27 - Framework Support Jasmine Mocha Cucumber 12:59 - What You Need to Know to Work with Protractor Node.js Debugging Knowledge 14:14 - Data Hydration for Tests 16:10 - Using Mock Modules 17:52 - When Should People Start Using Protractor? 23:21 - Using Protractor for Performance Testing benchpress 25:06 - Writing End-to-End Tests 29:28 - Testing Stories The PageObject Pattern [YouTube] Jim Lavin: Using Page Objects in AngularJS Protractor Authentication User Scripts Red Flag: Logic in Your End-to-End Tests 32:05 - Protractor 2.0?! 33:33 - Support for Angular 2   See Also [YouTube] Julie Ralph: End to End Angular Testing with Protractor ​ Picks bardjs (John) [Pluralsight] Play by Play: John Papa and Ward Bell (John) The revolution that could change the way your child is taught (Ward) Teach Like a Champion: 49 Techniques that Put Students on the Path to College (K-12) by Doug Lemov (Ward) Colt Express (Joe) ng-book (Chuck) DevTools: State Of The Union 2015 by Addy Osmani (Julie) Digital Spring Cleaning (Julie)  

01:20 - Julie Ralph Introduction Twitter GitHub Google (Seattle Office) Angular Team Protractor 02:47 - Finding Angular and the Team 04:50 - End-to-End Testing WebDriver 08:46 - Making Scripting Easier with Protractor 10:57 - Grabbing By Model 11:27 - Framework Support Jasmine Mocha Cucumber 12:59 - What You Need to Know to Work with Protractor Node.js Debugging Knowledge 14:14 - Data Hydration for Tests 16:10 - Using Mock Modules 17:52 - When Should People Start Using Protractor? 23:21 - Using Protractor for Performance Testing benchpress 25:06 - Writing End-to-End Tests 29:28 - Testing Stories The PageObject Pattern [YouTube] Jim Lavin: Using Page Objects in AngularJS Protractor Authentication User Scripts Red Flag: Logic in Your End-to-End Tests 32:05 - Protractor 2.0?! 33:33 - Support for Angular 2   See Also [YouTube] Julie Ralph: End to End Angular Testing with Protractor ​ Picks bardjs (John) [Pluralsight] Play by Play: John Papa and Ward Bell (John) The revolution that could change the way your child is taught (Ward) Teach Like a Champion: 49 Techniques that Put Students on the Path to College (K-12) by Doug Lemov (Ward) Colt Express (Joe) ng-book (Chuck) DevTools: State Of The Union 2015 by Addy Osmani (Julie) Digital Spring Cleaning (Julie)  

本期是测试小道消息技术篇的第一章。我们请来了快钱的一个测试妹子来介绍了webdriver和selenium，为了大家熟悉appium做了铺垫。我们会给大家带来更多的技术小道消息~谢谢。PS：今天我刚从南京沙龙回来，吐槽了一下南京的情况。

Find out how changes to the Selenium framework take version 2 to a new level, where WebDriver fits into the picture, and how the Android and iPhone support enhances mobile web testing (which is notoriously tricky). Interested in leveraging the cloud for testing? Then you'll not want to miss Simon's "Spinal Tap" analogy for some background.