RSpec and Rails 5
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 12 | |
| Number of Parts | 89 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/31554 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 201612 / 89
1
2
3
5
7
8
11
12
19
22
28
29
30
31
33
45
47
50
52
53
58
62
67
71
74
76
77
78
79
80
81
84
85
86
88
89
00:00
MereologySubject indexingPlastikkarteElectronic visual displayAbstractionSubsetType theoryComputer animationLecture/Conference
01:25
Presentation of a groupSlide ruleSoftware testingLie groupDoubling the cubeMeeting/Interview
01:58
BitCategory of beingPower (physics)HookingFamilySampling (statistics)Design by contractFrequencyAuthorizationComputer animation
03:24
Source codeCore dumpComputer animation
03:59
Commitment schemeRight angleOptical disc driveError messageMultiplication signPerspective (visual)Computer animation
04:36
Revision controlOcean currentTerm (mathematics)Object (grammar)Turbo-CodeComputer animation
05:08
Group actionSoftware suiteCodeSpacetimeSoftware testingHookingTurbo-CodeObject (grammar)Cache (computing)Semiconductor memoryCartesian coordinate systemSound effectComputer animation
05:39
Type theoryEndliche ModelltheorieCodeOrder (biology)Context awarenessComputer animation
06:27
Multiplication signComputer animationLecture/ConferenceMeeting/Interview
07:09
TwitterFeedbackRule of inferenceQuicksortTable (information)Computer simulationComputer animationMeeting/Interview
07:41
Software testingSoftwareDoubling the cubeVibrationFeedbackComa BerenicesOptical disc driveSlide ruleFault-tolerant systemNetwork topologyVideo gameCovering spaceComputer programmingComputer animation
08:25
Real numberArray data structureVideo gameMessage passingOpen setDescriptive statisticsFraction (mathematics)Computer animation
09:14
Control flowMathematicsRevision controlSoftware maintenanceMoment (mathematics)DemosceneComputer animation
09:49
Software testingGame controllerMathematicsFunctional (mathematics)QuicksortWritingElectronic visual displayImplementationMechanism designInstance (computer science)Variable (mathematics)Template (C++)Computer animation
10:32
Game controllerSoftware testingInheritance (object-oriented programming)Goodness of fitGreatest elementPoint (geometry)Execution unitDataflowComputer animationLecture/Conference
11:22
Game controllerMiddlewareFrequencyVolumenvisualisierungVariable (mathematics)Message passingRootSemiconductor memoryTemplate (C++)Level (video gaming)Error messageLimit of a sequenceQuicksortPhysical systemPoint (geometry)CausalityLie groupComputer animation
12:20
Computer fileGoodness of fitImplementationGame controllerSoftware testingDependent and independent variablesRevision controlSoftware maintenanceMiddlewareView (database)BitINTEGRALReal numberKeyboard shortcutOptical disc driveArithmetic meanCore dumpForcing (mathematics)Right angleExterior algebraQuicksortRule of inferenceWordMultiplication signReading (process)Computer animation
14:02
Game controllerImplementationDependent and independent variablesMobile appComplete metric spaceSoftware testingTemplate (C++)BitComputer animation
14:34
Software testingOnline helpBitGroup actionGame controllerGame theoryRight angleWrapper (data mining)Open setSystem callRandomizationWeb browserInternetworkingClosed setRow (database)TwitterType theoryMultiplication signCausalityComputer animation
15:39
Error messageInternetworkingAttribute grammarFundamental theorem of algebraDependent and independent variablesReal numberGroup actionOptical disc driveEngineering drawingComputer animation
16:34
TheorySlide ruleVideo gameSoftware testingGroup actionSuite (music)Database transactionFocus (optics)Software suiteMereologyComputer forensicsOnline helpComputer animation
17:21
Key (cryptography)Software testingSoftwareDichotomyFeedbackDirection (geometry)Endliche ModelltheorieCycle (graph theory)QuicksortMereologyComputer animation
18:54
FrequencyGame controllerOrder (biology)Bit rateSoftware testingLie groupEndliche ModelltheorieView (database)Perspective (visual)Right angleShared memoryComputer animation
19:30
Software testingMultiplication signDifferent (Kate Ryan album)Metropolitan area networkQuicksortEndliche ModelltheorieBlogPoint (geometry)MathematicsParameter (computer programming)Rule of inferenceDisk read-and-write headCodeDatabaseComputer animation
20:52
NP-hardMultiplication signCycle (graph theory)Data conversionSoftware testingCodeBookmark (World Wide Web)Sound effectSoftware frameworkDependent and independent variablesOrder (biology)Instance (computer science)Group actionSoftware developerPhysical systemSocial classCommon Language InfrastructureFrictionState of matterBlock (periodic table)Set (mathematics)Computer animation
23:24
Hecke operatorTraffic reportingPerspective (visual)Forcing (mathematics)Software testingSlide ruleBitNP-hardFrictionPlug-in (computing)Task (computing)Different (Kate Ryan album)AnalogyCommon Language InfrastructureShift operatorProjective planeProblemorientierte ProgrammierspracheFunction (mathematics)Social classGodParameter (computer programming)Exception handlingQuicksortAdditionBuildingLogicContext awarenessCongruence subgroupDialectArithmetic meanAreaError messageLevel (video gaming)Computer animation
25:25
Software testingSoftware bugMultiplication signCASE <Informatik>Right angleWordComputer clusterProjective planeMetreInteractive televisionExpert systemMathematical analysisComputer animation
27:04
Software testingMultiplication signBitComputer animation
27:34
Software testingAuthorizationProcess (computing)CodeComputer animation
28:24
AbstractionReading (process)Right angleTimestampRule of inferenceBlogGroup actionSimultaneous localization and mappingComputer animation
29:02
BlogBitNumberTime zoneGroup actionProcess (computing)Revision controlDichotomyMultiplication signPlug-in (computing)Similarity (geometry)ResultantSoftware testingGoodness of fitBuildingRule of inferenceComputer animation
30:55
Process (computing)Negative numberWeb pageHacker (term)ResultantComputer animationDiagram
31:27
Open sourceComputer configurationOrder (biology)Physical systemWaveProcess (computing)Condition numberInternetworkingModal logicGoodness of fitComputer animation
32:29
Java appletSingle-precision floating-point formatProcess (computing)MultiplicationWeb browser
33:04
Point (geometry)WordCapability Maturity ModelNatural numberProcess (computing)ResultantFood energyMultiplication signSoftwareMultiplicationRun time (program lifecycle phase)Information technology consultingReal numberCode refactoringBitMobile appVideo gameResidual (numerical analysis)Arithmetic meanScaling (geometry)CodeInductive reasoningOrdinary differential equationBuildingCartesian coordinate systemComputer animation
35:30
Cartesian coordinate systemAxiom of choiceWeb pageHacker (term)Entire functionMultiplication signSocial classRight anglePrisoner's dilemmaComputer animation
36:29
Message passingCodeMultiplication signSoftware testingProcess (computing)Capability Maturity ModelImage resolutionWritingInclusion mapSoftwareObject-oriented programmingRight angleGoodness of fitKey (cryptography)Point (geometry)Computer animation
39:30
Software developerInformation technology consultingSoftware testingMultiplication signDoubling the cubeSoftwareMeeting/InterviewComputer animation
40:08
Computer animation
Transcript: English(auto-generated)
00:02
All right, so when you walked in, you saw this.
00:20
That's me, that's Justin Searles, but you can see how it's written by hand on an index card. There's a story behind that. This is not my talk, which is part of why I'm so nervous. But really, please don't leave. You're in the right place, at least. So you just stay where you are, and I'm going to do my best despite this. This is actually not acceptable. I'm being trolled so hard.
00:50
Okay, so this is not a bait-and-switch. I've spoken at RailsConf two times before, and I intentionally wrote abstracts to get in through the CFP, and then I talked about what I wanted to talk about. So this is not a bait-and-switch like those two.
01:02
It wasn't intentionally that. It is now. This was supposed to be Sam Pippin's talk. Everyone go follow Sam. He's great. Sadly, Sam is in the hospital, so he wasn't able to give this talk, and that's why I'm here instead. But it's a British hospital, so he's just in hospital.
01:24
So send your good wishes to Sam. Why me? Why am I here? Well, Sam likes to give conference presentations wearing my company's branded T-shirt, Test Double, so people are often mistaking him for one of our employees, such that he actually now has intro slides like, I do not work for Test Double,
01:43
but I love them and also Searle's, which I heartily appreciate. We love you too, Sam. That's why we're here. You're a great member of the community. So this talk's going to be fippin' great. The only problem is I finally understand imposter syndrome.
02:00
So I've got a little bit of imposter syndrome because I am a literal imposter today in three main categories. One, I am not British, and as we all know, as Americans, those of us in the room who are American, everything out of British people's mouths sounds a lot more intelligent, so I have that shortcoming. And therefore, today I resolve to use fewer contractions,
02:22
to speak with authority, and to drop the erotic R. So let's practice this sentence together. Minitest is not better than RSpec. All right. I feel better already. Two, I lack Sam's glorious mane. I don't have a big bushy beard.
02:42
Sam, of course, derives his RSpec powers from his beard. This is obvious because why else would he have it? So I have not shaved since I agreed to do this at 7 a.m. Friday morning. Some scraggles. So I now know a few things based on the RSpec beard powers.
03:03
One, beards are itchy. Two, RSpec. And three, what beard oil is. So if anyone, I forgot my razor, true story.
03:22
If anyone has some beard oil on them, hook a brother up. Third way in which I am an imposter today, I am not on RSpec core. Here is a little organizational chart of where I fit in to RSpec. That's RSpec core, and that's me not being in it.
03:40
But you know what? Apparently it's just not a RailsConf without a talk from an RSpec committer about RSpec. So far, to date, the only RSpec thing I've committed to is this talk. So I decided to become an RSpec committer, right? It sounds like a good idea. So let's get started.
04:00
I'm going to make my first RSpec commit right here. I am so committed right now to RSpec. All right, so I'm just going to push it up. Access denied. So I tried everything earlier in the hotel. So let's try one more time. It always works.
04:22
You know what? You get this error message also when GitHub's down. So it's probably just that GitHub's down. So as this talk's resident RSpec committer, I have some startling announcements to make. I'm here ready to announce the future of RSpec for you today. Current version of RSpec is 3.4.0.
04:40
I'm here to announce the next major release of RSpec, RSpec 5. RSpec 5 is going to be revolutionary because we have some really awesome headline features that are very convenient to me and my purposes. The first, TurboSpec. Let me tell you about TurboSpec.
05:09
TurboSpec dumps the object space into the cache, into memory, after running every single one of your before hooks. It does this so that it can cache each nested example group setup code so that you don't have to run it across all your tests.
05:22
And then if you run the RSpec CLI with tack tack turbo button, it speeds up your tests. TurboSpec is going to make all of our slow RSpec suites way faster. Warning, it doesn't work if your application has side effects. But for the rest of us, it's going to be just awesome.
05:41
I have another feature for RSpec 5 that I think is going to really just make true believers of RSpec happy. Spec specs. You just create a spec of type spec, and then you can say things like, hey, this model order, I expect it to have five specs.
06:08
I expect order to finish within about two hours, to have 95% code coverage, to limit the nesting and indentation to just three contexts, to usually pass, and to be good code.
06:23
I don't know why they didn't have this in RSpec 3, it's in RSpec 5. Remember, it's important to spec spec your spec specs, people. Let's not get lazy. Obama's saying things.
06:45
Audio doesn't work anymore because of their shenanigans. Let's try one more time. What he said was, Justin, just give it a rest. I'm going to be, now I'm not going to sleep tonight.
07:01
So, thanks audio. All right. So, I'm still, anyway, regardless, I'm not sure if I'm cured or if I'm still impostering. You know, I am not Sam. If you don't know me, this is what I look like on Twitter when I'm getting retweeted for saying terrible things. That's me, Searls.
07:21
I'd love if you became my Twitter friend and got me some feedback about how things are going. I know it's not great so far. This is the Justin Searls marriage simulator. Basically, it's just you sitting across the table with me looking at my phone and making slanted faces. So we can all empathize with Becky Joy a little better.
07:40
This is me on brand. I help run a software agency called Test Double. Our mission is audacious. We're just trying to make the world's software less awful. And I'd love if you got us any feedback. Hello at testdouble.com. All right. So, again, talk title. Back to basics. RSpec, Rails 5.
08:01
What's there to know? By the way, sidebar. Did you know Sam rejected my RailsConf talk? I just thought I should mention that because I am supposedly honor bound to cover all this Rails 5 stuff because it's important to cover for the purpose of the program,
08:22
which I took with just nothing but grace. So Rails 5 stuff. My first question to Sam via text message on Friday morning was, will RSpec just work with Rails 5? No. And he was saying it as an implementer, right? He was thinking about all the work they needed to do
08:41
because obviously if you've ever maintained a gem, new slash major Rails releases break gems in surprising and myriad ways. I went and searched for just open GitHub issues that are demanding Rails 5 support. Just search for it and you get a whole lot of salty randos saying, hey, Rails 5 is not supported.
09:03
No description. Give me Rails 5. You owe me. Come on. Gems. Work. Work. Give me. Rails 5 is not even out yet, people. So if you know a maintainer, go give a maintainer a hug
09:21
because seriously, Rails major release upgrades are big work. RSpec considers this to be feature work. They don't want to make any breaking changes. They want you to be able to upgrade very gracefully. That's why they respect Semver as much as I don't. They're at 340 now. It's gonna be 3.5.0, which means that they have to keep it running
09:41
for older versions of Rails but also new versions of Rails. So I hope that you take a moment to thank the RSpec team for their thankless work because everything that they're doing here is behind the scenes. But there is one change that we all have to know about, which is, is it true that functional tests and controller specs are really deprecated? Well, yes, it actually is true. They're going away with Rails 5.
10:02
They're deprecated, at least not deprecated, to which I say finally. If you don't write controller specs, by the way, feel free to just play with your phone for this portion of the talk. If you do, it all started when DHH opened this issue, saying the mechanism for verifying
10:21
that you assigned a particular instance variable in a controller, making sure that a particular template was going to get rendered, those are testing implementation. Those aren't really valuable. Let's deprecate functional tests. And I feel like he was absolutely right. That was a really good point. And of course, if you disagree, you might disagree just because you write controller specs.
10:41
But here's my beef with controller specs. This is the testing pyramid here. At the top of the testing pyramid, it's just a way to illustrate these are full stack tests that call through everything in reality. And stuff at the bottom, these are just unit tests. Stuff in the middle are difficult to explain tests. And that's what controller specs are. So the problem, right?
11:04
The opportunity. I'm so glad to be one of those just chill, go with the flow kind of guys.
11:22
All right, so the problem with controller specs at this level is that above that point in the pyramid, there are untestable things that can break. And so they're only of limited value. And everything below it, the messages that you get are going to give you unclear reasons why things are going to fail because it might be something way, way deep below you
11:40
that is actually the root cause of the failure and the error messages aren't going to be very helpful. So it helps you in that very skinny way, but I don't know how much value that really adds. Another thing about controller specs that sucks is that they were a lie to begin with. Their API implies that a request is being made. So if you've got a controller, you do like get index, like you're actually making an HTTP request.
12:00
And then you have these assertions like you render this template or you redirect it or you have this HTTP status. Oh, look, I'm making a request. Wrong. It's just like, that's just really silly sugar of a facade and it's just invoking your controller methods, which means all this other stuff is not happening, like middleware is not getting invoked. So your controller specs might be passing when your controller is totally busted.
12:21
But they're faster. And that's why they exist. And they might be faster at runtime, but in my experience, they're much slower at fixed time. They're just a maintenance nightmare for all that no value that they provide. So, but, you know, despite the criticism of controller specs, there's Semver, right? So RSpec is promising not to break our tests with Rails 5.
12:42
The way that we are doing that, the way that you do that, all that you have to do is add this gem to your gem file called Rails Controller Testing, which will reintroduce the functional testing bits that RSpec Rails needs. And then meanwhile, the RSpec team is doing the hard work to make it seamless. It's my understanding Sam Phippen's doing a lot of that work.
13:00
And I hope that's not what put him in the hospital. So thanks to Sam and the RSpec core team. If you already have a lot of controller specs, stop writing those now. There's stuff that you can do instead of controller specs in the future. Here's some alternatives. One, you could write full stack feature tests that test that everything's fully working when everything's really integrated.
13:20
You could also do nothing. I do nothing. I have not written a controller spec for seven years. And you could also do request specs, which are very similar. We'll talk about those in a second. Because request specs are like honest versions of controller specs. They map to mini test integration tests in Rails.
13:43
And the reason that they're honest is that the API looks the same and the assertions look the same, except it actually exercises the routing, the middlewares and the views. So if something blows up, you know it's a good blow up. Another cool thing is because it's using rack test, you have access to the response body and you can make assertions on the actual response that's generated instead of all this weird implementation stuff.
14:03
When to use request specs instead of controller specs or nothing. Specs that assert a complete API response, like if you've got a JSON API and you can assert everything that it does, cool. Request specs are probably the right layer to test that. Specs that just assert you're assigning certain IVRs or rendering certain templates, eh.
14:20
It's needlessly coupled to the implementation. Probably don't need a request spec. Specs that assert HTML that comes out of the response body, probably not a good idea unless your app has absolutely no JavaScript, which is probably unlikely. So that's a bit about request specs, controller specs. Third bit. It was in the abstract, right,
14:41
that we're gonna learn how to test action cables. Does RSpec help us test action cable? No. Turns out that action cable testing isn't built into Rails yet. There's an open pull request and I assume that when that ships, RSpec will have a wrapper for it or something. So just test through the browser for now and make sure your website works.
15:01
All right, there we go. You're now ready to RSpec with Rails 5. Thanks very much, Sam, for trusting me with your talk. There's nothing more for you to see here. You can close Skype, Sarah. There's nothing, I think he's actually like maybe here. I think I see him waving, actually. Hi, Sam. Yeah, he just looks excited.
15:23
Yep, all right, bye, Sam. So one time, Aaron Patterson's up in the front row. One time, I texted Aaron something and he tweeted it and got a million retweets and I felt really salty about that because I was like, no, that was my random internet meme that I copied and pasted. And he sent me this in response.
15:43
It's not fundamental attribution error. It's internet attribution error. So this is my talk. RSpec and Rails 5.
16:00
Why are you here? Really? Like, shout it out. Somebody tell me why you're here. No. Next question. So why did you come to this talk, especially if you didn't know who I was? Something RSpec related? Anyone?
16:23
What's that? Okay, thanks. Thank you. Action cable. Thank you. RSpec cable. Well, I had two theories because I couldn't make the slides after asking you.
16:42
One, how the hell do I test action cable? Sorry for those people because I don't know. Two, I'm not happy with my test suite. And now I have a third theory, too, like, you know, I'm new here and what the hell is all this about because it's just like a lot of forensics and who are these people? I'll focus on the one that I can actually address,
17:01
which is what happens when we're still not happy with our test suites. Well, if you have this motivation and that's part of why you came to this talk, maybe you were thinking, like, well, RSpec might have a new feature that'll help me hate my tests less. Or maybe Rails has some new thing or removes a new thing that will help make the pain stop, make my test suite more sane.
17:22
I think that's a natural thing to do, especially when you're in a conference or you're here to learn about technology. We're searching for tools, and tools are easy because we can grab them off a shelf and use them, but they're way easier than, like, critical introspection, asking ourselves hard questions like, maybe it's our fault that we have terrible tests. There's two keys to happiness
17:41
with testing or anything in software. One, the tools that we use. Two, how we use those tools. And it's not a two-step recipe. It is a false dichotomy to, like, blame one side or the other. Some people will say, like, oh, well, clearly we just need better tools whenever we have a problem. And some people have a disposition that says,
18:02
well, no, we just have to think differently. We have to design harder. Like, if the tool's failing us, we're not using it hard enough. And that's not a good mental model either. I like to think of it as, like, first there were people thinking, and they were doing stuff, and then they wrote tools to help them do their job, and then the tools, our actual usage of them
18:21
informs how we think about the problem, and it's this hopefully virtuous cycle, this feedback loop. So I do believe that tools matter. Tools aren't everything. But tools are important, and we're gonna talk about how tools prompt behavior. Some tools guide us in a healthy direction to build good stuff. Some tools enable our bad habits.
18:43
And some tools just are written to be relatively low opinion, not very opinionated. First, I want to talk about a tool that enables a lot of bad habits. You might have heard of it. It's called RSpec Rails. And I feel like whoever invented RSpec Rails
19:00
was like, here's our marching orders. We're gonna just do whatever Rails does and then wrap it with RCLI and DSL as uncritically as possible. So you got controllers? Yeah, we can spec them, great, without thinking whether that was a good idea. You got a testing pyramid? We got a testing pyramid.
19:20
You want model specs and controller specs and helper specs and view specs and routing specs and request specs? Sure, and have feature tests, too. Just why not have all these layers? And honestly, as somebody who's, especially when I was a novice coming in, I was like, well, clearly, our tools are built for good reason. They have a good reason for having all these different tests test all the fucking time.
19:41
That's great, okay. So I thought, like, I looked at that, and I was like, man, I got my work cut out for me to, like, live up to this seven-layer nacho of testing. And what I came to realize over through a lot of usage is, like, well, all those tests are very integrated. Every single one of them will call through to the database. And additionally, they're very redundant. When I have a new model that I'm writing here,
20:02
and I make a change there, I have this incidental coverage in all the tests above it, so all those tests now need to be updated as well. That creates a lot of, like, low-value work just cleaning up all my tests. So here's, pro tip, here's how I use RSpec Rails. This is a secret. My secret to using RSpec Rails
20:22
is I have this whole thing, and then I blow away all of them except for sometimes feature specs and sometimes model specs. And then if I have any sort of Ruby that's, like, at all interesting, I'll write it in Ruby code, and then I'll test it with plain old RSpec. And that's the only way I've been able to find sanity with RSpec Rails. But it's not the tool's fault, per se,
20:41
but I had to fight that tool to get to this point. I had to fight all the documentation and all the blog posts and all of the arguments with people about why I was having problems. And that was not an example of a great tool experience. Let me tell you about an, like, experience with a tool that I thought was really, really helpful and great. Its name is RSpec.
21:00
RSpec itself is actually really awesome, but I think that a lot of people have a hard time with RSpec Rails, and then they turn around and they blame RSpec, too, and I think that's kind of unfair. It's worth it to, like, look at them separately. So let's talk about what makes RSpec kind of cool. First of all, I don't believe that RSpec is a test framework, per se. I think it's better to think of RSpec as a framework for helping you write better tests.
21:24
RSpec influences our design. It was designed to do that. You know, it was a response to XUnit with lots of repetitive methods that were all set up, like tons of tests set up in action and assert. But what was cool about nested example groups is, we can see the same symmetry,
21:41
like, and have very terse tests that aren't redundant, but we don't lose any clarity through drawing it up. That's my favorite thing about RSpec style testing. Additionally, I love that the assertions guide the naming for our methods. If I write this test and the thing doesn't exist yet, by using this matcher be silent,
22:01
it's going to assume that there's an instance method called silent question mark on that class, which is a really handy way to inform that the usage is sensible. Like, that's a natural name now. Additionally, years ago, when I learned about Let, I was pairing with Corey Haynes. Corey is a really smart developer.
22:21
He really looked up to him, and he's like, Let is great, because it lets you call out your setup stuff, create a new user, and assign it to this method, and even better, it's lazily evaluated. And I was like, I don't know, Corey. I worship you, so lazily evaluated sounds sweet. That's great. I'm going to use Let for everything, so I'd use Let a lot. And then another feature,
22:40
Let Bang, which will eagerly invoke that block, it has this interesting thing, because people generally find Let Bang by being like, well, I want this to run in exactly this order. I want to make sure that it invokes. And so Jim Weirich and I paired, and he looked at my code base, and he's like, dude, you're doing this totally wrong. Don't just use Let Bang for absolutely everything.
23:02
It's like there to draw out your attention to side effects in your code. It should be minimal. You should have them very, very sparingly. If you need to have a side effect in order for your code to work, that means that you have this coupling of state, not just to the arguments, but to other stuff happening in the system. So that's why there's a bang. It means don't do it.
23:21
So that was an interesting conversation that I never would have had if it wasn't for RSpec. Additionally, RSpec reduces friction. The CLI is great because it's really convenient, easy to use, pretty obvious, helps you focus on just what you want to run, has good output, and that's all work that I'd have to do if I was building my own rake tasks and my own
23:41
testing CLI stuff on every project. And I love RSpec's built-in reporters. Oh my god, we're at 30 minutes because of all the AV stuff. Please don't leave. All the reporters you need. So you have all the CI stuff that you need. There's so many RSpec plugins. I love that I get to focus on just my tests
24:02
and not the stuff around my tests. Additionally, RSpec fosters empathy. The API is designed to let you have a place to write in what the heck you're doing, describe the slide and how it complements RSpec. You have this opportunity in there to tell a little bit of your story in a way that's congruent with your tests. Another thing I love is that it shifts your perspective.
24:22
So RSpec has a domain-specific language. It does not look like normal Ruby. And that is a level of indirection. However, it forces me to think of my methods not just as methods, but like outside in, what's it like to use them? What's it like from the perspective of a stakeholder? What's it like under a different context? I really like the DSL for forcing me
24:41
out of just thinking of just methods and classes. Another tool talking about tools prompting behavior. It's possible to write tools that just don't have a whole lot of opinions. Minitest is a good example of one such tool, and it has a different priority than RSpec. Analogy I picked up from Aaron this week is you could think of Minitest as a race car.
25:01
It's why DHH uses Minitest, by the way, if you don't know. It's lean, mean. It's essential. It's only what you need to get your tests written. It's all pure Ruby, except it has these hard bucket seats. Versus RSpec, a luxury sedan with a lot of knobs and dials, but it's mostly full-featured and quite comfortable to ride in.
25:21
If you want a comfortable seat, RSpec offers you this rich Corinthian leather experience that you can just sit in and feel comfortable. The zeitgeist right now, and by the way, if you don't know the word zeitgeist, it's a German word for Time Snapchat. The zeitgeist
25:44
right now is saying that Minitest is really hot. When I talk to all my friends, a lot of them have dropped RSpec, started using Minitest. I think it's just really popular right now. I think that one of the reasons is people generally spread fear and uncertainty and doubt about RSpec that it's too
26:02
verbose, it's bloated, it's slow, it's too much indirection, it's better just to write pure Ruby. You ain't gonna need it. I'm here, too. I use Minitest on a lot of my projects. I like Minitest just fine. I like that it doesn't have very many opinions and it gets out of my way and I can just write just the tests I want, but of course I carry with me the fact that I actually
26:22
very finely, after years and years, I have my own testing opinions that I know work very well for me, and I can write tests without getting myself into too much trouble usually. But if you're not a testing expert, and you don't want to be a testing expert, or if you're on a team with novices, what I would suggest is like, remember, I learned a lot
26:40
discussing RSpec and grappling with its API and its features with past teammates. And I think that you might benefit from that, too, if you haven't had that experience yet. So yeah, on one hand, RSpec takes longer to learn, but when you learn how to use RSpec, you're also learning stuff about design and testing, and so maybe that's not so much a bug as a feature in some cases.
27:02
So if you're still not happy with your test suite, I suspect that you might be looking for a tool to solve your problems when instead we can use our brains and use thinking instead and change our approach. Oddly enough, at RubyConf last year, I gave a talk on exactly that. You can find it called is.gd slash stop hate. It's called how to stop hating your tests,
27:21
and it's not about tools, it's just about thinking. All right, so in the time remaining, I'm going to get a little bit more meta. Why are we here really? The fact that anyone came to this talk worries me.
27:43
They would not have come to this talk. Let me explain. Let me back up. First of all, giving somebody else's talk is a lot like testing their code, because I've had to open up all of Sam's work and his notes and stuff and try to understand what he was going to say here today. If you see something confusing
28:01
when you're looking at somebody else's code and you're trying to write tests for it or trying to review it, it's easy to think they're obviously a moron. It's important to assume that the author is smart and intelligent and had reasons. Meanwhile, if you see something that's obviously awesome, great, it's still your job to put on a critical hat and
28:21
investigate it anyway and ask the hard questions about why we're here. So let's critique this talk. Not the stuff that I said, just the Sam stuff. The stuff I said is fine. This is the abstract. I assume you've read it. I won't reread it or anything. This is his abstract. This is the first thing I read when he texted
28:41
me to see if I could give this talk. This is my opinion of the abstract. People like peanut butter, people like chocolate, slam them together, rspec-rails. This talk, I felt like I read the abstract. I'm like, this could be a six-paragraph blog post. And so the next thing I did was I Googled rspec-rails-5
29:02
and found Sam's six-paragraph blog post. I was just thinking, I was mad. I was like, why was this talk selected here? How did this talk fly through the CFP process without any criticality whatsoever? Like, that just doesn't
29:20
seem right. Now, granted, my talk was rejected, and I'm a little bit biased. I might be a little salty. But when I thought about it, I think that the reason was that this was a safe talk. This is a comfortable talk. This is well within everyone here's comfort zones. I use rspec. I use rails. Let's find out what's new. Great.
29:42
But I feel like that comfort should scare us because when we're in a group like this that's maturing, we're getting up to major version numbers like five. You know, comfort can breed complacency. So rspec, if we're just content with where things are and we're pretty happy with rspec and we're just happy to see, you know, like
30:00
little tiny tweaks here and there and make sure it continues to support stuff in the future, you're not writing blog posts about this new rspec thing. You're not writing new tools. You're talking about rspec less, even if rspec does everything you want it to do. Minitest, meanwhile, lately, like a zeitgeist, I've seen a lot of people talking up minitest, writing more plugins, educating
30:20
people a little bit more with blog posts, and as a result, it's getting a little bit more attention. So if a new person walks into the room, they're going to see people talking about minitest more than rspec. They're going to tend to go towards minitest, not rspec. So this reminds me a little bit of a similar dichotomy. Rails. Rails is pretty mature now. It's over 10 years old. It solves the
30:40
problems that it solves really well, and it's pretty well known what it's good at and what it's not. So people talk about Rails a little bit less. Especially all of us busy getting stuff done and building things, we're not out there advocating Rails anymore because we get to use Rails at work, which is itself fantastic. However, when you look at jobs, Rails jobs are on the decline. They're not just slowing
31:01
down. It's negative growth. There's this other thing, the technology that shall not be named. Everyone's talking about node.js. Like it or not, 900% year-over-year growth in jobs on Rails. There's a lot of activity there.
31:21
And it's not about, this is not a contest of who's the better technology or who solves stuff better. It's what's the front page of hacker news. So my challenge is, thinking about this talk and why the hell we're giving this talk and why we're here, that was ironic. Because that's one of
31:47
our options. The other option, if we're not willing to be uncomfortable, is we're going to see Ruby jobs start to dry up. And there might be fewer people at RailsConf 2018 than this year. Another way to
32:01
think about this is, if you're not familiar, Ruby Together is a nonprofit that pays people to work on Ruby open source. Another way to think about this is to ask, what were the conditions necessary in order for Ruby Together to seem like a necessary and good idea? Well, when an ecosystem is popular, everything's easy, because there's just wave after
32:21
wave of person on the internet who's going to write open source for free just for the ego, just for the fame, to be attributed to the new popular thing. Also easy, sponsored stuff. Like, Oracle backs Java. Java's not going to go anywhere because Oracle's incentivized for Java to be successful. Google is
32:40
not going to drop Go unless they feel like it. Talked to Mike, but JavaScript cannot die. Because multiple vendors have staked their businesses on it. Every single browser,
33:01
JavaScript is not going to go anywhere, so it's a pretty safe bet. We talk about RSpec, it's mature at this point. And I don't mean mature as like a four-letter word. Mature means mostly done. Bundler is mature. Rails is mature. Ruby is mature. They mostly do what they need to do to do their job well.
33:21
But that means, as a result, that when you maintain a popular gem like RSpec, it no longer makes you rich and famous, necessarily. And the ecosystem, the stuff that they had to do just to make RSpec continue working with Rails 5 is almost all stuff that you don't actually see. It's all internals, it's legacy code refactoring. No one really wants to do that. And so the reason Ruby Together needs to exist is
33:41
because the energy and the funding to keep Ruby competitive isn't there otherwise. And that is disconcerting, because Ruby Together isn't going to ever be big enough to solve that fundamental systemic problem. So let's talk about my real job. Sales. I spent a lot of time talking to business people about software
34:00
solutions and building software apps and stuff. And entrepreneurs that I talk to are always talking about certain technologies that they hear about that are advice to them. Like the meme stack, like Mongo, Express, Angular, and by the way, when people, I've talked to multiple business people this year who are like, yeah, we're going to build a new application, we're going to do it all on
34:21
Angular 1.X. Like, people are teaching business people, oh, you don't want Angular 2, just stay on 1 forever. Like, I don't get it. We're just going to wait, wait it out. And Node.js, the so-called meme stack. A lot of entrepreneurs are pushing this kind of stuff. Another one, a lot of people are just assuming, based on
34:41
trendiness, Node and React are just the way to go. You know who's talking about Ruby and Rails nowadays out in the marketplace? Like, has the ear of CTOs and directors of engineering? People spreading fear, uncertainty, and doubt because they have their preferred upstart technology that's faster or whatever, and what those businesses are hearing is that there aren't
35:01
enough Rubyists out there, that the Rubyists that do exist cost too much, that Ruby is slow, and that RSpec doesn't scale, either at runtime or operationally. Now, if you're in the room, you're like, no, no, no, Ruby's fine, this is okay, but I think that this is like a real important bit of anic data from the life of Justin Serles we all need to deal with
35:23
to help solve my consulting sales problem. Because I don't like sales. But that's why it's so frustrating as Rails is still the best choice for entire classes of applications. But because we stopped saying it a few years ago,
35:42
businesses stopped hearing it. People only share new stuff that excites them, that's novel. If you were to discover immortality today, it would drop off the front page of Hacker News after a week or two. People wouldn't be talking about it, they'd find some new shiny thing,
36:01
they'd be talking about React Native 1.0. And not that you just, you know, defeated death. Even though that thing is way more objectively better, it's not novel after a certain bit of time. So the dilemma, right? Ruby is no longer new, Ruby is still good. We gotta do something
36:21
so Ruby can remain relevant and we can keep working on Ruby at work. What's the we-do-something part? Remember, Ruby's mature. It does its job mostly well, and one thing that I think our community, that technologists need to get comfortable with, is that it is okay
36:40
for tools to be mostly finished. It is okay for software to just mostly do its job and be good at what it does. In any other industry, it would be ridiculous for us to say otherwise, that like, oh, it's clearly obsolete now because it's not super active and they're not adding new features. At a certain point, it just does what it needs to do. Remember I said the keys to happiness
37:01
were our tools, we all like Ruby, we like Rails, that's why you're here, and how we use them. So maybe it's time for us as a community to de-emphasize the tools and start talking more about how we use those tools to accomplish really cool stuff. Because there's all these evergreen problems in software, there's all these problems we're never gonna solve.
37:20
We're never gonna solve testing, we're gonna just get asymptotically better each time. We're never gonna solve design, because we're always gonna find new ways to design code. And human issues are never gonna be solved either, right? How our code communicates its intent to its reader is never gonna be solved. I swear, I get like
37:44
five bonus minutes. Sarah, can I have a minute? She's nodding very tepidly. So we gotta tell stories that help people solve problems in ways that are more than just look at this new
38:00
shiny bobble. And if you love Ruby, tell your story in Ruby and associate it back with Ruby so that Ruby remains known as a community of people who really get object-oriented design right, who get testing right, who get community and inclusiveness right. Being known for those things and having people talk about those things are enough to keep us relevant. And when you
38:20
think about whose job this is, remember that most of the people who made Ruby so famous in the first place don't write Ruby anymore. Their chapter is complete. Most of them have moved on to other ecosystems, some of them are no longer even with us. And that means that keeping Ruby relevant is not somebody else's job. I hate to break it to you, but the fact that you show up to a conference
38:40
called RailsConf in a room that holds just a couple hundred people means that you're one of the top couple hundred people whose job this is now, to keep Ruby relevant if you care. So my message is make Ruby great again.
39:07
Make Ruby great again. And tell your story. We don't have the time to talk about it today. Use this hashtag and tell me something that you could do to tell a story that might change something.
39:20
That might have an impact on others and might convince them that Ruby is a better solution than the technology that shall not be named for whatever it is that you're doing. Again, my name is Ryan Reynolds. I'd love to be your friend. I'm going to be here for the rest of the week. If you want to help us in our mission to fix how the world writes software, consider joining Test Double. We're always hiring
39:42
great developers. If your company is looking for senior developers and you're struggling to find people to add to your team, our developer consultants are great senior developers who would love to work on your team with you and build stuff alongside you. If you don't want either of those things but you want a sticker, I've got stickers too. And most importantly, thank you all so much for your time. I really, really appreciate it.