 All right, my name is Ed and I'm here today to talk about Cucumber, which is an automation tool, and I'll introduce myself a bit and then I want to get to know you guys. So my name is Ed Wyanco and back in the 1900s, I graduated from University of Pittsburgh and launched into a development career at that point. And now I've wound up as a quality engineer and I work at the Technology Development Center under Steve, but I'm not an understudy to Steve, but physically under Steve. So that's the hard data about me. Fun fact, more than a thousand times I've jumped out of a perfectly good airplane and one time out of one that wasn't so perfectly good, but that's a story for another time. All right, so let's get to know you guys. How many here tonight consider yourselves developers? A few? Yeah, okay, well, that's more than a few. All right, and how many consider yourselves QA? Yeah, great, great. And out of the QA, who's doing automation right now? Okay, maybe, yeah, a little less than half of the people. And who wants to do and is not yet doing automation? Or is thinking about it? Okay, yeah, good. All right, so you guys will be particularly interested, but hopefully everyone else will be interested as well to learn about Cucumber. Has anyone here heard about Cucumber before? Oh, yeah, all right, great. So good, good, good. All right, so just to set the stage, there's a lot of automation tools out there. And if you're not involved with them, they can probably all look the same. So just real briefly, why, why do we have so many automation tools? Well, and why would we want to do automation? It's a heavy lift. Why would we want to do it? Just you may already be aware of this, but it's going to free you up to do more exploratory testing rather than the same old stuff yet again, just to make sure your app works. It's your security blanket, you know, to make sure things are still working right. It's going to do things faster than a human can. It's going to repeat them with more precision than a human can. And it's going to give you more coverage of the different scenarios. So those are the reasons for automation. All right, let's go just a quick history. We're going to use our way back machine to do a little quick history on Cucumber. 2008, ASLAC HellSoy started the project. That was after the 1900s. And it was based on Dan North's RSpec story runner. I don't know if anyone's heard of that. And that was based on RBehave, which was a Ruby port of JBehave. Anyone familiar with any of those terms? Yeah, three, four of you. All right, don't worry about it. You know, that doesn't matter. You'll get a lot out of this without that. If you want to look that stuff up later, but don't worry, you'll, you'll be fine. So five key things. If you walk away from this that you should take away about Cucumber if nothing else. Number one, it's free. So that's good. It runs on Windows, Mac, or Linux. So that's a good thing. The very most key thing I think is communication. It helps with communication. And I'll talk more how it does that. A little far away from the, all right. So it tests, you can test web websites, APIs, but a whole lot more actually too. So the title was a little bit misleading. It's not just a UI testing tool. You can use it for a lot of other things that you'll see. And with Cucumber, there's an English part and a code part. All right. So how is Cucumber different and cool? There's my friend there with a different looking Cucumber. So let's zoom in and see how Cucumber is different and cool. So as I mentioned, I use it for web testing and REST API testing. But you can use it for lots of other things. Java, JVM languages. There's a wire protocol for TCP sockets. You can test mobile with it. You can dot net mono, Flex, Flash and ActionScript, JavaScript, NodeJS, iOS, PHP, C++. There's a lot of platforms that it supports if you get the right plug-in. And all that information is out there on GitHub. And I'll make all these links that I'm flashing up there. They'll be available in some form after the meeting if you're interested. All right. So has anyone heard of behavior-driven development before? Yeah, quite a few. That's awesome. All right. So for those of you that don't know what it is, does anyone want to give a two or three sentence your opinion of or your understanding of what behavior-driven development is? Anyone want to go? Go ahead. Exactly. Yeah, that's great. Great summarization of it. Yeah. The business analysts usually are the ones defining the behaviors and providing concrete examples. And then the team, the rest of the team, creates and tests each feature per those expectations. And again, if you don't know what behavior-driven development is, if you've never heard of that before, that's okay. Just take away that it's cucumbers considered a BDD tool. And you don't really have to be doing BDD to use cucumber. You can still use it. All right. So Guy on the left says, no, I think you're misinterpreting it. And then Dilbert says, wait a minute, I wrote it. So probably a lot of us have been in those situations where things are interpreted differently. There's a miscommunication and it causes like a few days work to get thrown away or have to be redone and stuff like that. I'm sure we've all been there, right? So the idea, ASLAC's idea with this tool is to bring these worlds together, the requirements world, the automated testing world, the documentation world. And analogous with that, our requirements often sit in one system and that tests it in another one and then the documentation's in yet another one. So the idea here is that cucumber can cover all these three areas and reduce communication problems. And we'll see that in the English part coming up next. All right. So the two parts, the English part and the code part. So the English part, the way we set our words up, the syntax of it is called gherkin. And has anyone ever used or the given one then kind of syntax before? Probably, yeah, good. So just like you have a certain syntax when you're writing a user story in Agile, this has a certain given one and then syntax to help us communicate clearly. So the given sets the context. You're usually talking about maybe what user you're logged in and what screen you're at or where you're at in your app and what's happened up to this point. The when describes an event, the thing that happens that you're testing and then the then describes your expected result. And an example of that. So the scenario is like a test name. So this scenario is refunded items, increased stock counts. Given a customer previously bought a black sweater, anytime you see and you're just adding on to the thing. So adding to the context here. So given the customer previously bought about black sweater and there are currently three black sweaters in stock, when the sweaters returned for the refund, so that's the key event here, then our expected result, there are now four black sweaters in stock. So it's should be pretty, pretty clear to everyone what's going on. Business analyst is going to understand that. So should the QAN developer. And for the code part, you have what are called the step definitions. So the English part of the steps and the code part are the step definitions. They're commonly done in Ruby, but they can be done in other languages, Python, JavaScript, Java and several others there. All right. So I'm going to move on to a demo next, but one last thing before I do that. Should you be further interested in Cucumber? The great book written by the man himself, Aslak Helsoy along with Matt Wynn, the Cucumber book. You can, I believe you can find that on Amazon. There's a site pragmatic books I think that has it. So you can get a PDF. The great, it's a great place to start if you want more information on Cucumber. All right. So I'll do a little demo now. So the text is very huge. One that back just a little bit. Let's see here. Let's move this over. Okay. So typically what we do for the, these, there are feature files that organize our scenarios, our test scenarios. So a lot of times a feature will correspond to a user story or cover several user stories. So sometimes what I do is just use the story text in the feature. So you have the, as a internet user, I want to have a search function so that I can see valuable pictures of cats. So, so in this scenario, I have a smoke test. And so given that the user Bob has opened the browser, when the user loads Google.com, then a blank search input box is presented. And so that's the English part. And the code part that corresponds with it. In this case, I did it in Ruby. So Ruby, so the, when Cucumbers run it, it goes through all the feature files or whichever feature file you select and interprets each line. So it encounters the line that says user Bob has opened the browser. And so it'll look for a matching step in your steps definitions in your step definitions. So here it'll find this particular step. And in this case, the browser is already going to be open for us. So in this simplistic example, there's nothing really to do. So I just have a comment there. And I know Steve somewhere is cringing that I have a comment in my code. So I apologize, Steve. So when the user loads Google.com, it's going to go through and it's using regular expressions to match the steps. And so here, we're going to grab the URL into a parameter based on that regular expression. So really, this step is more valuable than a simple hard coded step because we're going to be able to launch any, any website we want really with this step. I'm using what's called capybara, which is like a plug in or a gem you can use to enhance cucumber. So we're just saying visit URL, pretty simple. And our then step, a blank search input box is presented. We're basically using the find field. And it'll search by ID, but this is flexible enough to use CSS expressions or XPath expressions. So if we didn't have a handy ID to use an HTML ID, we could find this field based on any other property that has the text within the element or by other elements around this element. So it's pretty flexible. So I'll go ahead and run this. I can see what cucumber does. And you can see given user Bob has opened a browser. And there comes the browser. And it's looking for that search input box. And it's there. Great. Past. And I want to take the example just a little bit further to show you neat things about how cucumber works here and how it's behavior driven. So I have another scenario here. And I'm going to enable it. This is a tag, this at symbol. So I'm actually kind of showing what user story it goes with in case we want traceability. And this one says this is an actual search. So it's more than a smoke test. So given user Bob has opened the browser and the user loads Google.com, when the user searches for cats, then the search results include cat dash Wikipedia. So I don't have definitions for these last two steps yet because I've defined the behavior before I've implemented the code. So let's save this and see what cucumber does when there are no definitions for some of the steps. Run cucumber again. So given Bob has opened a browser. And you'll notice it's Firefox coming up. So by default, cucumber works with Firefox, but it's relatively easy to modify it to run against Chrome. Firefox and Chrome behave very similarly as probably a lot of you experienced. And then you can run it against IE, but that's more challenging. The setup is easy, but IE behaves differently than Chrome and Firefox, so it's challenging for that reason. You may have to change the way you're identifying elements to run against IE. So let's take a quick look at what that output is. Bob's opened a browser, he loads Google.com. And then we see these steps. Hopefully you can see they're in yellow. So the two scenarios actually ran both scenarios because I didn't tell it to just run one. So it ran both one pass, one was undefined or had undefined steps. Here are the two undefined steps. And it says you can implement step definitions for these undefined steps with these snippets. And it gives you snippets which you can cut and paste into your steps. And you can implement the steps then. So it gives you a nice head start in implementing your steps. Yep, time up. All right. Very good. Okay. Very good. All right. Thanks, everybody.