00:00:11.960
Hi everyone! I'm really excited to be at RailsConf this year. My name is Eileen Uchitelle, and I am a senior systems engineer on GitHub's Platform Systems team. That's quite a mouthful, but it basically means that my team is responsible for working on internal and external tools for the GitHub applications. We work on improving Rails, Ruby, and other open-source libraries as well, focusing on how those tools interact with GitHub.
00:00:30.269
I'm also the newest member of the Rails core team, which means that I've finally gained access to the official Twitter account, because we all know how important Twitter can be! You can find me on GitHub, Seeger, Dex, and Twitter with the handle EileenCode, which also includes my website. It's all the same.
00:00:51.930
Today, we're going to talk about the new system testing framework in Rails that I've spent the last six months building. We'll take an in-depth look at my process for building system tests, the roadblocks I encountered, and what's unique about developing a feature for open-source software.
00:01:18.180
But first, let's travel back in time a few years to the 2014 RailsConf, where DHH declared that test-driven development (TDD) was dead. He suggested that though TDD had good intentions, it was ultimately used to make developers feel bad about how they wrote their code. DHH insisted that we needed to replace test-driven development with something that motivates programmers to test how applications function as a whole.
00:01:29.759
In a follow-up blog post titled 'TDD is Dead, Long Live Testing,' DHH stated that today Rails does nothing to encourage full system tests; there’s no default answer in the stack, which he regarded as a mistake. Fast forward three years after this declaration, I’m excited to announce that Rails 5.1 will finally make good on that promise by incorporating system tests into the default stack. The newest version of Rails includes Capybara integration, enabling developers to run system tests with zero application configuration.
00:02:06.670
By generating a new scaffold in a Rails 5.1 application, you will have everything needed for system testing without having to change or install anything. It just works! Now, it’s a good time to clarify what a system test is. Many are familiar with Capybara being referred to as an acceptance testing framework, but the ideology of system testing in Rails is much broader than that.
00:02:31.709
The intention of system tests is to test the entire application as a whole entity. This means that instead of assessing individual components or units of your application, you examine how those components integrate with one another. With unit testing, you can check that your model requires a name, but in a separate test, you'd validate that the controller detects an error. This doesn't guarantee the view displays that error message, but with system testing, all of this becomes possible.
00:03:07.230
You can test that when a user omits their name, the appropriate error message is displayed in the view and the user actually sees it. System tests also allow you to examine how your JavaScript interacts with your models, views, and controllers, which isn't possible with any other testing framework in Rails right now. Before we dive deeper into what system tests look like and how they were built, let’s discuss what happens when you generate a new Rails 5.1 application.
00:03:43.350
When you create a new Rails 5.1 app, your Gemfile will automatically include the Capybara and Selenium WebDriver gems. Capybara is locked to version 2.13.0 and above to enable the use of features pushed upstream. Additionally, like many test assertions in your test directory, a system test helper file called ApplicationSystemTestCase will also be generated. This file includes the public API for your Capybara setup. By default, applications will utilize the Selenium driver using the Chrome browser with a custom screen size of 1400 by 1400.
00:05:13.170
If your application necessitates further setup for Capybara, you can include all that configuration within this file. Every system test you write will inherit from ApplicationSystemTestCase. Therefore, writing a system test is not much different from writing Capybara tests, except that Rails now provides all of the URL helpers.
00:05:30.630
You can use host URL and post path instead of '/post' without requiring any additional configuration. Here is a simple test that navigates to the post index and asserts that the h1 selector is present with the text 'Posts.' You can run system tests from your terminal using the command 'rails test system.'
00:05:56.820
We do not run system tests as part of the whole suite because they are slower than unit tests, and everyone we've talked to usually runs them in a separate CI build. However, if you want this test to run with your entire suite, you can create a custom rake task that allows that. Let's take a look at system tests in action. I had to record the demo because they move quite fast, and you wouldn't be able to see it unless I slowed it down.
00:06:28.580
So first, we’ll write a test for creating a post. The test visits the post URL, then instructs the test to click on the 'New Post' link in the view. Next, we fill in the attributes for the post, where the title will be 'System Test Demo,' and the content will just say 'Lorem Ipsum.' Just like a user would, we'd click on the 'Create Post' button. After a redirect, we are going to assert that the text on the page matches the title of the blog post.
00:07:01.410
You can run the system test with the command 'rails test system.' You will see that the Puma server starts up and Chrome opens, where the test fills in the details just as we specified. It’s incredibly straightforward, and the tests run quite fast! You might be wondering why it took three years to develop system tests since they don't seem that complicated.
00:07:34.360
In reality, while I worked on it for six months, there were several reasons it took three years for system tests to become a reality. First, system tests needed to inherit from integration tests to access the existing URL helpers; however, integration tests were initially really slow.
00:08:03.170
The performance of integration tests was abysmal; there was no way for the Rails team to push system testing through integration tests without significant backlash from the community. No one wants our test suite to subtly shift from five minutes to ten minutes, which is an unacceptable performance impact. Thus, the improvement of integration test speed had to happen before implementing system tests. In 2014 and 2015, I collaborated with Aaron Patterson to enhance integration test performance.
00:08:43.060
Once integration tests became marginally slower than controller tests, system tests could inherit from them. Another reason it took three years is that, contrary to popular belief, the Rails core team does not maintain a secret Rails feature roadmap. Rails is a volunteer effort, so if there's no one interested in implementing a feature, it simply won't be done.
00:09:09.420
Individually, we may have ideas of what we’d like to see in Rails 6, 7, or 8, but it's not a roadmap. We all work on what we are passionate about, and often features grow out of actual challenges faced by our applications at work. System tests are a prime example of this. Before joining GitHub, I was a programmer at Basecamp, where we decided to add system testing through Capybara while building Basecamp 3.
00:09:52.390
I experienced firsthand how much effort it took to get system testing working in our application, which inspired me to work on adding this feature to Rails 5.1 so that others would not have to go through the same amount of work to set up system tests. This past August, David asked me if I would be interested in integrating Capybara into Rails 5.1.
00:10:33.100
These were his exact words. Most of my work in Rails had involved performance improvements, refactorings, or bug fixes, so I was genuinely excited to work on a brand new feature for the Rails framework. There was just one caveat: I had never used Capybara before. I know that sounds ridiculous, but apart from writing three or four system tests in Basecamp, which I admittedly struggled with, I had never set up an application for Capybara or written an entire test suite.
00:11:25.320
However, this lack of experience had its advantages. It allowed me to understand firsthand the challenges involved in configuring Capybara, especially from a beginner's perspective. I had no preconceived notions about what would be easy or difficult when I started developing system tests. This fresh perspective allowed me to design the feature solely from the viewpoint of what would work best for Rails and Rails applications.
00:12:21.350
This is not to say that Capybara does anything wrong; however, Rails is highly opinionated about what code should look like and how it should feel. It was crucial to ensure that implementing system tests was straightforward and required minimal setup so that programmers could focus on their code rather than test configuration.
00:12:48.700
When implementing something unfamiliar, it's beneficial to have guiding principles to aid in design and decision-making. Without clear goals, it's easy to get entangled in scope creep or get bogged down in trivial debates about implementation details. I utilized the Rails Doctrine for guidance in building system tests. As previously mentioned, the Rails Doctrine consists of a set of nine pillars that guide decision-making in code within the Rails ecosystem.
00:13:11.310
While developing system tests, I regularly based my decisions on the Rails Doctrine. System tests needed to meet all these requirements in some form. I would like to address a couple of the principles and how the system test infrastructure aligns with them. The first principle is optimizing for programmer happiness. This pillar encompasses the entire intent of Rails: to make programmers happy.
00:13:52.180
I personally feel spoiled by this approach; Rails indeed makes me happy, and I'm sure it makes all of you happy too, or you wouldn't be here at RailsConf! However, one aspect that did not bring me joy was the extensive implementation required to get Capybara running in our Rails applications. The bare minimum code required for your application to use Puma, Selenium, and Chrome made many applications repeat this setup multiple times.
00:14:29.950
To accommodate multiple drivers or to support various browsers or custom settings, extensive setup was often essential. Rails 5.1 system tests now mean you can use Capybara without needing to configure anything in your application. When you generate a new Rails 5.1 application, the setup necessary for system tests is automatically completed for you. Programmer happiness drives the effort to get system testing into your application and into Rails.
00:15:16.060
You won't have to figure out how to initialize Capybara for a Rails application, set a driver, or pass browser settings. The system tests in Rails abstract away all this complexity so you can focus on writing code that makes you smile. You only need a simple little method, 'driven by,' when generating a new application.
00:15:38.090
When you generate a new Rails app, a test helper file is also generated. If you upgrade your application, this file will be created when you generate your first system test or scaffold. The previously discussed code is encapsulated within this one method, driven by. This method initializes Capybara for your Rails app, sets the driver to Selenium, the browser to Chrome, and customizes the screen size.
00:15:59.990
Rails values being a single, monolithic framework that addresses the entire challenge of building system tests—from databases to views to web sockets and testing methodologies. By being an integrated system, Rails reduces duplication and external dependencies, allowing you to focus on building your application rather than installing and configuring outside tools. Prior to Rails 5.1, we did not address the need for system tests, but now that this feature has been added, Rails has become a more complete, robust, and integrated system.
00:16:40.580
As the 2014 RailsConf demonstrated, Rails was incomplete when it came to system tests, but Rails 5.1 closes that gap by adding Capybara integration. You no longer need to look outside of Rails to introduce system testing in your applications.
00:17:07.740
One of Rails’ values is progress over stability. This means that often betas, release candidates, and even final releases can contain a few bugs; however, it also indicates that Rails has not stagnated over time. With many years of development, the progress we've achieved is remarkable. We care about our users, but we also prioritize the framework meeting the demands of the present and future, which sometimes involves making improvements that are not yet entirely stable.
00:17:31.950
While it might take years to ascertain that a feature is perfect, the reality is you often don't know for certain until it’s utilized by someone else. I could have spent years working on testing and improving system tests; however, I chose to merge them when I knew they had only a few bugs left. I made this decision because I was confident that the community would identify solutions for the problems I hadn't solved and would uncover new issues in the implementation that I hadn’t considered.
00:18:10.270
By valuing progress over stability, I decided to merge and learn from the system tests while they were approximately 95% done, instead of waiting until they were 100% stable. Community members tested the beta release and provided bug fixes for critical issues present in the system tests, and a few features were even added, moving some functionality upstream to Capybara.
00:18:41.740
Consequently, system tests advanced more by being merged while they were incomplete rather than waiting until they were ideally stable. Now that we've explored the driving principles behind system testing, let's examine the decisions around implementation and architecture of the Rails framework.
00:19:03.590
We will look at the configuration defaults, decisions I made regarding which driver to utilize, and the fundamental structure of system tests within the Rails framework. The first configuration default I’d like to highlight is why I chose Selenium as the default driver. The barrier to entry for using system tests should have zero setup and should be simple for beginners.
00:19:49.720
Capybara's default driver is RackTest, but I didn't feel this was a suitable default for system testing because RackTest cannot test JavaScript or take screenshots. It isn't a good default for beginners trying to learn how to test their systems. A few users mentioned on the pull request that they preferred Poltergeist because it was faster and that’s what they had used in their applications.
00:20:34.740
While it’s true that Poltergeist is popular and faster, I chose Selenium for several reasons. It doesn't require the same kind of system installations that Poltergeist does; for example, Poltergeist requires PhantomJS, and Capybara WebKit depends on Qt. Neither of these system dependencies is something Rails could responsibly mandate. Selenium does not have these additional requirements and, therefore, makes more sense as the default.
00:21:06.580
One of the cool features of Selenium is that you can actually watch it run in your browser. Poltergeist and Capybara WebKit are headless drivers, meaning they lack a graphical interface. While they produce screenshots and can test JavaScript, you can't visualize them in action. Watching Selenium tests run in a real browser such as Chrome or Firefox is almost enchanting!
00:21:43.090
This feature makes it much easier for new programmers, especially those learning Capybara, to see the test in action, which makes it easier to understand what is occurring and why they may be encountering issues. Another advantage of system tests is that if you prefer another driver instead of Selenium, changing the default driver is extremely easy.
00:22:08.490
To change the driver system tests use, open your system test helper and alter the 'driven by' method from Selenium to Poltergeist. Of course, you will need to install PhantomJS and include it in your Gemfile, but adjusting the driver settings is simple. Rails will not prevent you from passing in whatever driver you want, but Capybara exclusively accepts Selenium, Poltergeist, Capybara WebKit, and RackTest.
00:22:36.540
Another decision I made that diverges from Capybara defaults was using the Chrome browser with Selenium instead of Firefox. Chrome enjoys broader usage and a larger market share than Firefox, and the CanoE development is predominantly executed in Chrome, making it a sensible default. Initially, Firefox had issues and was broken with Selenium 2.53.
00:23:03.650
This was a significant motivator for me to establish Chrome as the default. If Firefox has been functioning with Selenium, you can upgrade both Firefox and your Selenium WebDriver gem to utilize Firefox. If you would like to switch to Firefox over Chrome, simply change the 'using' keyword argument from 'Chrome' to 'Firefox.'
00:23:28.360
The 'using' argument is exclusive to the Selenium driver since other drivers are headless and lack a GUI. I am eager to add support for more browsers in the future, such as Safari or Internet Explorer, depending on what users prefer. The 'driven by' method also accepts a few optional arguments supported by Selenium; for instance, the screen size argument sets the browser's maximum height and width, which is helpful for testing your website at various sizes.
00:24:09.630
The 'driven by' method also accepts an options hash, which is forwarded during browser initialization. This is beneficial for options that are not explicitly defined in Rails but accepted by Capybara, like the URL option. One of the coolest aspects of system tests is that they automatically capture screenshots when a test fails, which is useful for identifying failures.
00:24:42.060
This feature functions with all drivers supported by Capybara, except RackTest. Integrated in the system test codes in the Rails framework is an after teardown method that captures screenshots if the test fails. We will now take a look at these screenshots in action.
00:25:05.520
First, I will change the test assert statement to use 'Val' rather than 'Demo,' and we can run the test just as we have seen before. This will initiate the test, and now you can see that it has failed. In the test output, there is a link to an image of the screenshot.
00:25:35.280
We can open it and see the screenshot that captures the system test demo's text. So we can clearly illustrate why a failure occurred. Additionally, you can capture a screenshot at any point during your test by executing the method 'take screenshot.' This feature is invaluable for tools like CI for comparing integrations or saving a snapshot of what your website looks like at any moment during the test run.
00:25:55.170
One less obvious feature of system testing is that Database Cleaner is no longer a requirement. Those who have previously worked with Capybara may recall that transactions during Rails test runs with Capybara wouldn't get properly rolled back. This has been a long-standing issue where Active Record struggled to roll back transactions when tests were threaded.
00:26:32.430
The underlying issue is that when a test started, Rails' testing code would initiate a transaction with a database connection. However, the web server would open a separate connection to the database on a different thread. When tests conducted database inserts or updates on that second thread, these operations couldn't be seen through the thread with the transaction.
00:27:05.480
Because of this, when the test concluded, the inserted or updated records wouldn't be rolled back. Afterward, runs would fail due to uniqueness constraints or other issues arising from residual data left behind from previous tests. I spent considerable time during the six months building system tests trying to solve this dilemma.
00:27:35.450
To my surprise, many users had accepted this limitation with Rails for years. I was determined to identify a solution that would prevent users from encountering another dependency. To successfully fix this issue, I had to request assistance from two individuals more knowledgeable than myself regarding Active Record's concurrency: Aaron Patterson and Matthew Draper.
00:28:19.290
The challenge arose as Aaron and Matthew held differing opinions on the approach. I initially tried to rectify the issue following Aaron’s suggestion: to have Active Record check the connections back in after they were utilized. Unfortunately, this broke approximately 75% of the Active Record tests.
00:29:02.690
That wasn't a viable solution because you would be attempting to check the connection while transactions were open and in use. Matthew proposed an alternative solution, which was to have all threads utilize the same connections at the test's start. When a transaction began, a database connection would be opened, and when the Puma server started, it would be forced to connect using this existing connection.
00:29:49.080
This approach allowed all updates and inserts to operate on the same connection as the original test transaction, enabling everything to roll back when the test transaction ended. I certainly would not have figured out how to address this issue without their assistance, and you would likely still have to rely on Database Cleaner indefinitely.
00:30:24.220
We invested considerable effort exploring the individual settings in the public API for system tests, so now it's time to examine the underlying framework that supports all of this. The code we’ll review at this stage is not something you will ever need to adjust unless you encounter a bug. This code handles the configuration so you won't have to worry about it and can focus on writing your tests.
00:30:57.530
System tests reside in Action Pack under the Action Dispatcher namespace and inherit from integration tests to utilize the existing URL helpers that are already in place. This entire class is too lengthy to fit on a single slide, so I will categorize the methods as they are invoked during the test execution.
00:31:31.130
When you run a system test, the start application method is called first. This setups the rack app and initiates the Puma server. Your system test helper file subsequently calls the driven by method, where the default configuration settings are implemented. When the driver is invoked, a new system testing driver class is initialized with the parameters you provided, and the driver object is set with the designated browser, screen size, and options.
00:32:09.020
At this point, the running test is initialized. It is important to call 'use' on the driver here, ensuring that the driver is established when the test initializes and not before the class loads. The 'use' method registers the driver with Capybara, setting the browser to Chrome with the provided options and screen size. Finally, the 'used' method calls setup, which simply assigns the current driver method in Capybara to the driver you've specified.
00:32:36.050
This basic framework setup is required for Rails to get system tests functioning, and it's relatively simple, but it’s great that none of you have to include it in your application. One of the insights I gathered while developing this feature is that working on open-source projects is significantly different from building features for a product or client.
00:33:13.230
Typically, client work is kept secret until the big reveal, but here, almost all of the work I've done previously has involved performance improvements, refactors, or bug fixes—all technical elements that don't garner much community engagement. People typically don’t offer feedback on aspects that don’t affect the public API. However, adding a brand new testing framework is something everyone has opinions about.
00:33:59.400
When my system tests pull request was open for three months, I received 11 reviews and 161 comments, not including all the discussions had in Basecamp. This highlighted a significant challenge in open-source work: the feeling of vulnerability it can create. It can feel like every commit, every comment, and every piece of code is under public scrutiny, and that can be one of the most challenging aspects of working in open-source.
00:34:38.740
This experience can deter new contributors from engaging with open source. Even as a member of the Rails core team, I still feel that adrenaline rush every time I push to master, and I break into a sweat if the build fails after I merge a pull request. However, it's important to remember that engaging in public debate is inherent to open-source development.
00:35:06.050
It's an undeniable part of the process. When your confidence begins to waver, you might feel compelled to seek consensus amongst reviewers of your work. The desire to seek agreement is not unique to open-source work; however, the differentiation lies in the diverse levels of investment stakeholders have in the final outcome.
00:35:43.420
When building a feature for a company or a client, you generally know who your stakeholders are—the ones most invested in the feature. Conversely, in open-source projects, you won't know who will care until you open that pull request. I was aware that the Rails team was a stakeholder and that they cared greatly about the implementation of system tests.
00:36:24.330
Indeed, I was also aware of the Capybara team's interest in this feature's development. Nevertheless, I wasn't fully prepared for all the other community members who would be invested in it as well. While acknowledging that participation is good and I valued constructive feedback from the community, it was still a bit overwhelming to try to accommodate everyone’s opinions.
00:37:10.410
Rails ideologies of simplicity tend to conflict with those of Capybara, which emphasizes offering numerous features. Consequently, various individuals held differing perspectives on the best default driver—whether it was acceptable to change Capybara’s longstanding defaults from RackTest to Selenium, or if including screenshots as the default was appropriate or acceptable. Hence, I struggled to respect all opinions while maintaining a sense of ownership over the system tests.
00:37:47.300
I realized that trying to satisfy all three groups would ultimately result in a solution that failed to please any group. After all, consensus can often be the enemy of vision. While you may add everything everyone wants, the feature may end up losing focus, and the code may lose its style, and ultimately, I risk losing everything I felt was important.
00:38:26.700
I had to find a way to acknowledge everyone’s perspectives while also not compromising the coherence of system tests, which still needed to align with Rails' look and feel. To achieve this, I had to work within Capybara’s ideologies while keeping in mind that system testing should be robust and offer various options.
00:39:04.170
Though there's nothing inherently wrong with this approach, it doesn't abide by the Rails Doctrine, as Capybara did not provide a distinct pathway for getting system tests into Rails applications. It was ultimately the Rails team that decided on the merge of system tests. Therefore, I first honored the principles of Rails, followed by others’ input.
00:39:35.200
When you're building open-source functionalities, you're creating something that will benefit others. By being receptive to suggestions, you may enhance the feature's quality, even if you disagree with the feedback. It's crucial to be open to varying perspectives. I constantly had to remind myself that the work I was doing was intended for everyone, not just for me.
00:40:02.050
Open-source initiatives thrive on community contributions. Exemplifying this point, I merged system tests despite knowing they weren’t entirely stable. I did this because I recognized that contributors could assist in rectifying the issues once they had the opportunity to test them in real applications. Consequently, when the Rails team released candidate one less than a month after the initial beta, all the existing problems I was aware of had been fixed, thanks to the contributions of others.
00:40:40.220
Capybara's maintainer added mini-test assertions which users running system tests with mini-tests had previously encountered as incorrect due to Capybara handling those differently compared to RSpec. This was one issue I was unsure how to remedy. I understood that fixing it in the Rails code wasn’t appropriate, but I needed Capybara's collaboration to address it upstream. Fortunately, the maintainer was willing to add this change for Rails, which was a significant win.
00:41:06.780
Robin, another contributor, submitted a pull request that adjusted the test framework so that system tests wouldn’t run with the entire suite. We didn’t want system tests to execute when you executed Rails tests in your application since they could be slower due to using an actual browser. Instead, we'd like to run them in a separate test command.
00:41:28.550
These two contributors assisted in making the 'driven by' method more flexible, allowing it to function on a subclass basis rather than globally. When I initially designed system tests, I assumed that a Capybara power user would not need to set up 'driven by' frequently, but once it became evident that this was not the case, many users were excited about utilizing the method instead.
00:42:00.460
Furthermore, contributors helped enhance the screenshot functionality, ensuring they could be configured and displayed differently based on the environment settings, whether in CI or the terminal. I recognized that this was an area of concern when I merged system tests, but I wasn't certain how to resolve it. Fortunately, the contributor devised an elegant and user-friendly solution.
00:42:32.870
This was also their first contribution to the Rails framework, which highlights the intrinsic beauty of open source: it flourishes only through community involvement. Open-source development is meant to be collaborative; it doesn't function without contributions from others. While contributing to a mature framework like Rails can be challenging, Rails has a promising future thanks to all contributors who care.
00:43:05.000
Finally, don’t believe anyone who claims that Rails is dying, because the reality is that the future has never been brighter. Rails will benefit from your contributions in the future, just as the community requested improvements to the system tests. You too can impact Rails' future by contributing.
00:43:36.120
I sincerely hope to see some of you discussing your contributions to Rails and open source at next year's RailsConf 2018! Thank you for listening.
00:43:52.450
(Speaker takes questions.)
00:44:30.880
The first question was whether Rails will take a stance on promoting system tests over other types of tests. I would say the first consideration is the necessity of business needs, and now those needs are addressed by the inclusion of system tests. There are various testing types, and system tests tend to be slower due to browser usage and JavaScript involvement, which makes it impractical to push system tests as the only required option. We are not going to abolish unit tests within Rails.
00:45:24.670
The next question was how I find time to contribute to Rails and open-source projects while maintaining a full-time job. It is indeed a challenge. At times, I felt burnt out from working on system tests because I dedicated weekends to this effort. Balancing work can be complicated; I do have some time to allocate for open source, though it is not my primary job.
00:45:59.460
I find balance by engaging in work that I am genuinely passionate about, whether at GitHub or previously at Basecamp. When it comes to contributing, it is easy to convince your company to provide some open-source time—perhaps even one day a month—where you can work collaboratively on projects. Staying current with the Rails app you use at work can also help you better identify bugs.
00:46:37.740
As for how Rails prefers you structure your system tests, the 'driven by' method determines how you configure and set up your tests. We maintain an opinion regarding this process, like we have with other aspects of Capybara tests, without altering fundamental methods.”},{
00:47:22.680
The question was about the most exciting part of building this feature. Honestly, the most exhilarating moment was the day I merged it! It had been a long journey, with my pull request open for about three months. Merging was rewarding because everyone could finally use what I had built. Notably, this was one of the best-tested beta versions I had ever been a part of.
00:48:03.240
So it was thrilling to see so many bugs identified and resolved in our first round of testing—the number of fixes was unprecedented! The final question was about how I named the system test feature. I originally selected a name during our discussions in the Basecamp project that referenced the framework, and it was intended to be straightforward. However, the term didn't integrate well into Rails due to namespace issues.
00:48:34.630
Afterward, there was a debate about an appropriate name before the merge, leading to the final selection of 'ActionDispatch::SystemTestCase.' This experience further highlighted how peculiar integration tests are—you might even consider renaming them to 'IntegrationTestCase' for consistency! I apologize for running out of time—if you have more questions, please feel free to catch me afterward.
00:49:05.420
(Applause)
