Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
- So I have two items of business to take care of before we talk about Cucumber. These slides, this talk is open source. The slides that I'm using right now are available at tinyurl. com/cucumbers-have-layers. So if you have any trouble seeing the screen here, and my voice, following my train of thought or if you like spoilers, you can download a PDF of both my slides and my script, and read it on your very own device.
You can even download the slides now and walk out and see a different talk, and I won't be in no way offended. It's been really hard to choose from this program. It's been really great. The other thing that I want to mention is that I work for a company called Real Geeks.
We sell web-based tools for real estate agents. Real Estate, Real Geeks. Yeah. Anyway, I'm sure you'll be shocked, just shocked to learn that we are hiring. You may also want to know that our office is in Hawaii. I live in Portland, Oregon, and I work from home, but here's a photo from my last office visit.
This is my daughter and me looking at the full moon rising, and my partner, who took this photo, has it as a lock screen on her phone. That, in my opinion, this is the best perfect job. But anyway, we've got stuff in Ruby, Python and JavaScript. And, we especially need some help with React JS.
So if you're interested in writing software in Hawaii, come say hello. Also, I have stickers. So, with that out of the way, welcome. I'd like to get a quick show of hands. How many of you use Cucumber on any project large or small? Wow, almost everybody. Cool.
How many of you have used Cucumber more than one time? Okay. Cool. And regardless of whether you've used it once or more than once, how many of you would use it again? More than I thought. Okay. I see some maybes, but yeah. (chuckles) Well, this talk is directly aimed at people who may used Cucumber in the past and decided not to use it again.
I'm glad to see that less of you are in that camp than I thought there would be. But I hope for those people to offer you at least a different perspective, convince you to maybe at least give Cucumber another look. For those who, like three of you, who haven't used Cucumber, you should go get The Cucumber Book before you start.
It will give you a much better introduction than I could, even if this were a full 45 minutes of Cucumber 101. But just so you're not completely lost, in Cucumber, you describe features of your software in a language called Gherkin, and Gherkin is a DSL for writing acceptance test.
Now because this is a Ruby Conference, and we have a tendency to say DSL when we mean API, I have to clarify. When I say Gherkin is a DSL, I mean it is an actual domain specific language with its own grammar and semantics. Gherkin is not Turing complete, but it can be used to tell a Turing-equivalent machine what to do.
As I was saying, Gherkin is a DSL for describing software. Each separate Gherkin file's called a feature. Here's a feature directly from the Cucumber website. Feature has one or more scenarios. The scenario has one or more steps. Those are the given/when/then ones then that you see at the bottom left of the screen.
And aside from a few keywords, which I've highlighted here in green, everything else is written in whatever an actual language works for you. Gherkin's grammar is really simple. Everything from a keyword to the end of the line is treated, essentially, as a single token by the Gherkin parser.
And Gherkin is useful, quite useful just as documentation for your project, but Cucumber, of course, also lets you use these feature files to automate tests, which is why the people behind Cucumber like to talk about executable specifications. To go from human-readable documents to running tests, you do have to write a bunch of step definitions.
A step definitions is just a regular expression plus a block of code. This is how you translate from those human-friendly blobs of text to something that Ruby can actually execute. When Cucumber wants to run a step, it tests that step against every one of the regular expressions that you've given it.
When it finds a match, it executes the block that was associated with that regular expression. There's also a mechanism for taking captures from the regex and passing them as arguments to the block, which is how you can get interesting data into your tests.
And in my mind, Gherkin and Cucumber are almost two separate things. Gherkin gives you a human friendly way to describe software, and Cucumber processes your Gherkin files and uses them as a script for automating tests. And Cucumber can be kind of unwieldly.
I basically put up with Cucumber because I really like Gherkin. As I said, Gherkin is a DSL for, or rather it's a domain-specific language where the domain is talking to other humans about software. It's very free-form, so it lets you talk about your application's domain using whatever language makes sense to you and your team, and Gherkin has just enough structure that it can be used to drive a lot of machinery for automating tests, but.
. . Gherkin is not a programming language, as mentioned. This is a critically important point that I think a lot of people overlook or can overlook when they're starting out with Cucumber, and I draw this distinction because programming languages are great, but when we're using them, they require us to get all of the details right up front, and that process of writing code and fighting with a very nitpicky parser tends to shift our focus onto how to do a thing.
Gherkin, on the other hand, exists to help us think about what thing to do, why we're doing it, and even who we're doing it for. It's also important to realize that Cucumber is not really a tool for doing test-driven development. Cucumber and TDD complement each other nicely, but it's been my experience that Cucumber works on a very different rhythm than TDD does.
I think of Cucumber as a set of guide rails for TDD, and my workflow for using it goes something like this. I start with a Cucumber scenario. I run the scenario and watch it fail. Then I look at the error message to figure out why it failed, and use that information to go write a unit test.
I watch the unit test (audio cuts out) and refactor. At this point, I have a choice. If I (audio cuts out), I need to write is then I do that, and I go back around the red/green/refactor cycle, maybe several times. But if and when I get stuck, I go back to the Cucumber test again.
It's probably still failing, but it's failing for a different reason, and that helps me figure out what to do next. I go back into the TDD cycle again. Go around and around that inner loop. At some point, I run the Cucumber test and it passes. Do a little dance, refactor, move to the next scenario.
[ ... ]
Nota: se han omitido las otras 3.389 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.