00:00:11
Now it's working! Cool, thank you, Ran. Alright, my name is Mike Schutte, and I'm here to show you very little code but tell you a whole lot about how I think you should write it and the processes you should adopt mentally and in your workflow.
00:00:17
I appreciate you all coming out. I know it's late in the week, but we've learned a lot of really cool technical topics and different mental frameworks, and it's been super stimulating.
00:00:23
I know physically and mentally it’s a lot, so I appreciate you coming out, even if most of you are here because there was overflow from the sexier Webpacker topics.
00:00:35
Let's go ahead and cover the general scope of what we're going to cover today. I'm going to go unusually deep into my background, but I promise there's a purpose for that.
00:00:52
Then we're gonna get clear on our goals for today. I liked the previous talk about the victory condition, so we're going to take a second to ensure that we’re clear on that.
00:01:06
We'll talk a little bit about testing paradigms and the different ways we can go about testing.
00:01:11
Then we're going to dive deep into the point of this whole talk, which is to think of testing as more of a storytelling process and not just an obligation or a potential dopamine hit from a green test suite.
00:01:22
After that, we will do an experimental demo. I'm going to be looking for some help on that.
00:01:29
We'll walk through a potential actual process of applying product requirements or different specs into a story that could then be used to implement actual functionality.
00:01:42
Finally, we'll review what we covered to make sure we walk away with at least one substantive piece of information that will influence our work in the coming weeks and months.
00:01:55
Then we will be on our way, waiting for the awesome closing keynote.
00:02:03
So we have 51428, and I was going to try to show off some fancy proc syntax with Ruby, but then I remembered that it’s me, and you can just call it .some.
00:02:09
Thank you, Matt. So, I currently live in Detroit and work for a company called Quickly, which is a digital marketing platform. We get to use beautifully written Rails code, and we have some React front-end components.
00:02:21
We also have some ghost services for our high-traffic endpoints, encountering really interesting challenges that we get to solve.
00:02:34
My favorite one is that we have essentially hundreds of thousands of users hitting one endpoint in a matter of five minutes, which can be really interesting and sometimes overwhelming in terms of how we handle that.
00:02:47
As for how I got into coding, I studied environmental science in undergrad. With the environmental issues, I started to become more interested in social issues, which led me to add a sociology major.
00:03:00
This interest led me to serve as a City Year core member, a volunteer AmeriCorps program, where I worked with fifth graders in a classroom for a year. That was an incredible experience, filled with highs and lows.
00:03:14
It deepened my interest in structural systems, like understanding educational inequality and the societal factors that lead to some students having iPads while others have twenty-year-old textbooks.
00:03:26
Quickly, I found that I cared much more about sharing knowledge about sociology than just running regressions on big data models.
00:03:38
So, I decided to move back to Denver, where I was just about to take a job at a coffee shop, start writing about education, and maybe pursue music.
00:03:51
I had everything lined up to get into the gig economy, when my partner Hannah heard about a boot camp in Denver called Turing.
00:04:05
She wanted to check it out, and since she was interested in basic HTML/CSS and front-end technologies, I came along for moral support.
00:04:18
Five minutes in, we learned that Turing required a full-time commitment of 70 hours a week for seven months. Hannah, who had a good job, quickly lost interest.
00:04:32
Suddenly, with no programming experience and for no reason other than curiosity, I found myself super intrigued. One thing led to another, and I started caring about aligning my equal signs, having slim controllers, and viewing equal signs as assignment operators. The whole nerd life was a robust transition for me.
00:05:01
I was still able to pursue my love for long-distance running, writing music, and playing instruments like piano and guitar. I love reading fiction and writing poetry.
00:05:21
Now, you might be asking, why is this guy telling me so much about his life? I want to learn how to test, I want to learn how to write better tests!
00:05:32
There’s a reason for all this context. Context is critical when framing storytelling and how it can help you write better tests.
00:05:45
These are my goals for you: If you start to disagree with something or even become confused, just try to reorient yourself using these goals as a compass.
00:05:56
The goals are to enrich your understanding of what it means to test, why we test, how you can test, and to build confidence in your ability to write tests.
00:06:08
From experience, I know some people avoid writing tests because they feel unsure about what or how to test. This is silly because, in many ways, you have an innate human ability to write expressive and robust tests that can help you write better software.
00:06:30
So when talking about testing, we can mean a lot of different things. If you're interested, just in case you haven't encountered it, the adjective form of 'paradigm' is 'paradigmatic'.
00:06:53
In this context, I'm saying testing is paradigmatic because it's surrounded by certain assumptions and agreed-upon methodologies that lead to drastically different outcomes.
00:07:13
A lot of what we'll discuss will have slight and nuanced differences. It’s kind of like having angles; while the origins can be quite similar, the consequences and outputs can be very different.
00:07:26
So it's important to keep in mind that the way we think about doing this can make a big difference. One testing paradigm is 'test last,' which is pretty much what it sounds like.
00:07:50
You have somewhat functioning code, and then you remember, 'Oh, I should have some tests!' So you write a bunch of tests, and hopefully they pass. While this approach is better than nothing, it comes with hidden dangers.
00:08:02
You might have bugs embedded in your implementation, leading to false assurance from a green test, saying everything is okay when, in reality, the code includes an existing implementation.
00:08:14
'Test last' is one extreme camp where you tack testing on at the end. When we shift to a more 'test-first' or 'test-driven' paradigm, we benefit from the elegant design principle of 'red, green, refactor.'
00:08:32
This means we write the test first, and since we haven't written any code, we are in the red, which indicates a failing test. We can think of it as telling a story to our test suite or interpreter, describing certain functionality.
00:08:55
The computer hears this story and responds saying, 'This isn’t really happening; you’re saying this is the case, but I don’t see it.' So you get failures, and in Rails, the whole process is incredibly fulfilling.
00:09:07
It guides you through most basic functional requirements. Finally, you walk through those errors, implement a passing implementation, and then you're free to refactor!
00:09:19
The idea is to address one error at a time, stay focused, and use that test as guidance to achieve your overall goal. Once you have a passing test, you can refactor, and often, the refactoring will break the solution, leading to a failing test again.
00:09:37
This results in a hardening phase, similar to moving inward in a spiral, until you find a solution you're happy with—something you'd like to submit a pull request for.
00:10:15
However, calling it 'test first' is a bit misleading because this process feels more similar to 'test last' than 'test-driven.' You say, 'Okay, I have a requirement, and I pretty much know how I’ll do this. So how would I go about writing this test?'
00:10:30
I found clarity on the difference thanks to concepts introduced at this conference, like 'conceptual compression'—the idea of storing and compressing information in a way