00:00:11.990
Hello everyone, we're going to go through a lot of information today. My name is Nate Berkopec, and I'm excited to talk to you about Minitest.
00:00:21.960
You may have seen the program mentioned a guided read, and that’s exactly what we’re doing today. We are going to read code. This is basically a code reading talk.
00:00:33.570
While preparing for this talk, I realized that it's really about the pain associated with testing.
00:00:40.070
Testing often brings us pain, and we could have titled this talk, 'Minitest: It Hurt Me and I Liked It.' I write about full stack Ruby app performance at NateBerkopec.com. Performance is typically my focus. I don’t usually delve into testing, as testing is often the last item on my skill improvement list.
00:00:58.260
However, Minitest has played a significant role in my growth as a tester. As I will show you today, it has also contributed to my evolution as a Rubyist. That’s why I wanted to share this with you here today.
00:01:24.870
Let me start with a story. I began learning programming in 2010 as a college senior, with Ruby as my first programming language. I wanted to land a job at a big, flashy startup, and I thought becoming a programmer was the best way to achieve that.
00:01:42.479
When I started learning Ruby, I used Michael Hartl's Rails tutorial. With no computer science background, if you’ve seen that tutorial, you know he uses RSpec from the beginning and teaches TDD, which was quite challenging for me at the time.
00:02:13.680
As I was just beginning with Ruby, tackling testing was really tough. RSpec introduced me to concepts like 'describe' and other spec terminology that felt overwhelming.
00:02:35.490
Eventually, I found Minitest, and it was a breath of fresh air. I realized I could write tests in a more straightforward manner, just using Ruby. Many people who have worked with Minitest may have had a similar experience.
00:02:58.260
I appreciated its simplicity. However, I faced challenges while trying to stub an object in my tests. I became frustrated, feeling like Minitest didn’t provide ways to stub an instance method.
00:03:37.200
So, I turned to the Minitest IRC channel, expressing my frustration and comparing it to RSpec. Mike Moore, the maintainer of the Minitest Rails gem, explained that it could be done using Ruby’s singleton methods, which opened my eyes to new aspects of Ruby.
00:04:00.980
This experience began my deep appreciation for Minitest, where it led me to explore Ruby pieces I had never engaged with before. This journey through pain highlighted the challenging moments we experience in programming.
00:04:22.890
This talk is about Minitest, and since it’s in the 'Less Code' track, I must address RSpec. While the initial proposal stated that a less code implementation should be around 500 lines or fewer, Minitest is slightly larger.
00:05:07.080
Nevertheless, it’s still much smaller compared to RSpec, which has an entire library of features. I’m not here to start a debate between testing libraries; I aim to discuss the philosophy of Minitest.
00:05:38.330
Minitest should be viewed as a reactionary testing framework. The original Minitest was just 90 lines of code, created by Ryan Davis, who felt that Test::Unit was overly complex. He wanted to provide a simpler alternative, leading to the development of Minitest.
00:06:59.620
Before we read any code, we can learn a lot just from a project's file structure. A useful tool for assessing the size of a project is Cloc, which counts lines of code by language. Applying it to Minitest reveals that it has around 1,699 lines of documentation and approximately 1,586 lines of Ruby code.
00:07:46.390
In comparison, RSpec has multiple components and dependencies that add significant overhead. Minitest condenses everything into one gem, which can be beneficial for Rubyists seeking simplicity.
00:08:43.430
Minitest’s core philosophy is about doing less with less. Transitioning from RSpec’s many lines to Minitest’s concise structure requires a change in perspective. For example, RSpec’s formats consume 1,639 lines just for test result formatting, while Minitest focuses on efficiency.
00:09:57.780
In terms of mocking, RSpec's mocking library is approximately 28 times larger than Minitest’s equivalent. This exemplifies a philosophical difference; Minitest suggests avoiding complexities where they're not necessary.
00:10:49.580
The largest file in RSpec's core is configuration.rb, around 758 lines. Contrast that with Minitest’s largest file, which is only 446 lines. Minitest focuses on 'convention over configuration,' often guiding users in a particular direction rather than leaving them to configure extensively.
00:11:49.190
Minitest encourages a philosophy that lacks extensive configuration options, instead providing a clear path for users. In contrast, RSpec promotes flexibility and extensive customization, even humorously suggesting to users how they can make it their own.
00:12:43.380
Now, let's jump into Minitest. A simple Minitest code structure involves requiring the Minitest library and defining a test class that inherits from Minitest::Test. Each test method begins with 'test_' to signify it's a test case.
00:13:28.750
When executing our test files, Minitest manages test discovery natively without additional test runners that RSpec usually requires. You run it from the Ruby command line, demonstrating that Minitest is streamlined in that methodology.
00:14:23.590
Minitest represents a more straightforward implementation strategy. The methods are clearly defined without complex abstractions, contrasting to RSpec's verbose setup that incorporates more abstractions.
00:15:08.140
By analyzing Minitest's structure, we see that its design philosophy emphasizes readability and simplicity. Minitest avoids over-complicating the code pathways.
00:15:53.560
In cases where configuration may seem necessary, Minitest aids your path with simplicity rather than needlessly extending functionalities. Instead of making assumptions about what a user might want, it simplifies choices.
00:16:38.020
Looking further at Minitest’s assertions, we notice that assertion methods are straightforward. They allow users to create their own assertions as needed, emphasizing a tangible way to conduct validations.
00:17:14.620
I find that Minitest’s architecture encourages using available tools rather than layering unnecessary complexity over basic functionalities. For instance, assertions in Minitest are designed to be clear and concise.
00:18:00.320
In conclusion, Minitest represents an ideology centered around the benefits of simplicity and clarity. It reminds us that pain can be a guiding force in programming—leading us to refine our approaches and appreciate the nuances of coding.
00:18:42.820
As I wrap up, I encourage you all to explore the Minitest documentation and experiment with it. If you haven't already done so, I urge you to dive into Minitest and experience how straightforward it makes the testing process.
00:19:36.480
Thank you for your time today! If anyone has any questions, I'd be happy to answer them now.
00:19:56.640
Thank you for listening!
