Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
- We're gonna ever get through all these. Oh boy. Alright, so, my name is Nate, I'm gonna talk into the mic while I do this, here. And today we're gonna talk about Minitest. I know in the program it said a guided read, and we are gonna read code today. This is basically a code reading talk.
But, as I was writing this talk I realized it's really about pain. The pain that testing makes us feel. So we're gonna talk about pain. You probably could have titled this talk something else. Minitest: It Hurt Me And I Liked It. My name's Name's Nate Berkopec.
I write about full-stack Ruby app performance at Nateberkopec. com. Performance is my usual wheelhouse. I'm not a testing guy, I don't usually write about testing. Testing is sort of, the last thing on my code skill improvement list sometimes. But, Minitest played a huge part in my evolution as a tester, and, as I'm going to show you, as a Rubyist.
So that's why I wanted to come and talk about it here to you today. Oop, wrong way. I'm gonna start off by telling you a story. I started learning to program in 2010. I was a college senior. Ruby was my first programming language. I wanted to get a job at a big flashy startup, and I thought the best way to do that would be to become a programmer.
Turned out that was true. When I started learning Ruby I used Michael Hartl's Rails tutorial, I had no computer science background. And if you've ever looked at that, you know Michael Hartl does a great job of teaching you TDD from the start. But, he uses R-spec, and for a long time when I started with Ruby, testing was really hard for me.
I was just getting started with Ruby, I barely understood what I was doing with Ruby to begin with, and then along comes R-spec and there's sort of like, well you gotta learn "describe" and "it" and all these other words that R-spec concepts that R-spec brings to you, and says, you have to learn those, too.
And for a while that was really frustrating to me. And then I found Minitest. And it was kind of like a brand new day for me. It was like, oh, it's just Ruby, I can just write whatever I want, you might have heard this sort of line before if you've ever done anything with Minitest.
I knew the API was very simple and it was a lot easier for me as a beginning Rubyist to write. But. . . I came upon this test and I wanted to stub an object, I wanted to stub an object's instance method. And I was really frustrated, 'cause it seemed like there was no way in Minitest to do that.
And I went into the Minitest IRC channel, and I said, "Guys, this is dumb. "R-spec makes it really easy to do this, "and why won't you let me stub an instance method?" And Mike Moore, the maintainer of the Minitest Rails Gem, among other things, oops, I keep going the wrong direction, here, said, "Well, that's 'cause we already "have it in Ruby.
"It's called a singleton method. " I was like what? You can do that? And that sort of started this long love affair with Minitest where Minitest kept showing me parts of Ruby that I'd never looked at, or I'd never understood. And so, by reading Minitest source code, we can re-engage with Ruby.
In this way, pain, feeling this pain of, ugh it's really hard to do X-Y-Z, led me to learn something new about Ruby. Is this a talk about Minitest, it's in the Less Code track, so I do have to address the elephant in the room, and that is RSpec. I think the original CFP, or something, for this conference, this track specifically, said that Less Code was like 500 lines or less.
Minitest is not that small, but I did get into Less Code track anyway, and I think it's 'cause we all understand that Minitest is small in comparison to the other options that we usually reach for when testing in Ruby. But I'm not here to play internet fight, I'm not here to talk about RSpec, I'm here to talk about Minitest.
And to get it totally out there, I mean, it's pretty obvious, I came to give a talk about Minitest, I am a Minitest guy, so I want you to take everything I'm saying here with that grain of salt in mind, I don't want you to swallow everything I'm saying here just wholesale.
This talk is about the philosophy of Minitest revealed through its code, and we can't really talk about that without talking about RSpec, because a lot of what makes Minitest's philosophy so interesting is what it doesn't do. And we can't talk about what something doesn't do without talking about something that does it.
And in that way I think Minitest is best thought of as a reactionary testing framework. It's a reaction to other kinds, or other styles of testing. Bit of a history lesson here, the original Minitest was 90 lines of code. Ryan Davis, sitting right up here in front was nice enough to resurrect that version for me, and it's available there at "tinyurl.
com/originalminitest," for an interesting read. And if you've ever wanted to know what being terrified feels like, it's talking about someone's library while they're sitting in the front row. And Ryan has said in other conference talks that it was originally a replacement for test-unit.
He sat down, was saddled with the maintainership of test-unit, thought it was too complicated to even understand, and wanted to see if he could write something that did what test-unit does, but in less code. And it's from that beginning that we have Minitest, that we have today.
Before we actually read a single line of code though, I think you can learn a lot from a project's file structure, and its general, where its lines of codes live, and how many there are. So before I dig into a library, I think one of the greatest things you can do is open up Cloc.
It's this little library for counting the lines of code in a project, it's smart enough to break things out by file, to break things out by language, so if you have multiple languages in a project, it'll say, oh, well it's got ten thousand lines of Ruby and five thousand lines of Javascript and so on and so on.
And if we apply Cloc to Minitest, you get this crazy output, but the gist of it is, Minitest has 1,699 lines of documentation in the form of its readme, and all the non-blank comment lines. And just 1,586 lines of Ruby code. That's also blanks removed. That maybe sounds like a lot, I guess, a thousand is like, a big number.
But, let's take a look at something else, so RSpec has four major components. Minitest lives in one Gem. There's a huge plugin infrastructure, but if you Gem Minitest, there's no Minitest dash a million other things that get required. RSpec has four major components that get required when you add RSpec to your Gem file, that is rspec-core, expectations, mocks, and all three of those depend on something called rspec-support.
[ ... ]
Nota: se han omitido las otras 3.223 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.