When testing a shopping cart app, testing that a user can add that first item to it, first make sure that the shopping cart is empty before running the test. If the cart isn't empty, delete every item in the shopping cart. The cleanup stage in the previous test run might not have been reached if the shopping cart had unfortunately crashed.
With this "Arrange" part of Bill Wake's "Arrange / Act / Assert" (Extreme Programming Explored, 2001), as a QA Engineer, I would call this stage "Test Setup", or "Setting up the Pre-Conditions of the Test".
Playwright and Cypress calls this... seeding.
... Er, what? Why do they use that term?
Hey, Claude! How come I only have heard this term in the past year or two?
Claude's Response
If you have been working in QA automation for a while and only started hearing the term "seeding" in the last year or two, you are not behind. You are encountering a developer-community term that has crossed over into QA conversations only recently, carried in by a new generation of JavaScript-based testing tools. The concept itself is not new. The word is just new to this particular corner of the industry.
Where the Term Comes From
The term did not originate in testing tools. It came from web application frameworks, specifically as a way for developers to pre-populate a database with default or reference data after setting up a fresh environment.
Ruby on Rails formalized the concept in 2009, and the person who coined it is David Heinemeier Hansson - known throughout the developer community by his initials, DHH. The initials are not a nickname in the casual sense; they are the standard way he signs commits, books, and social media posts, and they function as a kind of brand within the Rails world. DHH is a Danish programmer, entrepreneur, and racing driver who created Ruby on Rails in 2003 while building Basecamp (then called 37signals) and released it as open source in 2004. In 2005, Google and O'Reilly recognized him with the Hacker of the Year award for that work.
Where did the term originate?
On August 18, 2009, DHH made a specific commit to the Rails repository introducing db/seeds.rb and the rake db:seed command. The commit message reads:
"Added db/seeds.rb as a default file for storing seed data for the database. Can be loaded with rake db:seed (or created alongside the db with db:setup). This is also known as the 'Stop Putting Gawd Damn Seed Data In Your Migrations' feature. [DHH]"
Developers had been placing initial data records directly inside database migration files, which caused real maintenance problems: migrations are meant to describe structural changes to a schema, not to populate rows of data, and mixing the two made both harder to manage. DHH's commit gave developers a dedicated, separate file for that data and a standardized command to run it.
The crude phrasing is consistent with how DHH communicates generally. He is widely described as one of the most outspoken figures in software development, someone who does not hide opinions or soften language when making a point. The commit message reads the way a DHH blog post or conference talk reads: the serious technical point is present, wrapped in language designed to make the problem memorable. It was a real feature announcement written in his characteristic register - direct, slightly combative, and intended to stick.
The word "seed" itself draws on the agricultural metaphor: you plant data into a blank database the way you plant seeds in bare soil, before the application can grow anything on top of it. DHH chose that metaphor, and it held.
How the Term Spread
The official Rails Active Record Migrations guide still documents db:seed as a core part of the framework to this day. Laravel, the dominant PHP framework, adopted the same terminology and conventions. Laravel's seeding documentation has an entire dedicated section on the subject, using a DatabaseSeeder class stored in a database/seeders directory, controlled via the db:seed Artisan command. Laravel 3.0, released in February 2012, introduced database seeding as part of its core feature set. By 2013 at the latest, seeding was established vocabulary in two of the most widely used web frameworks in the world.
So the term has been in active use in the developer community for roughly fifteen years.
Why QA Engineers Are Only Hearing It Now
For most of that period, the word lived inside developer and framework documentation, not in QA or test automation communities. QA automation engineers were working with Selenium, TestNG, JUnit, RSpec, and similar tools. The terminology in those communities for the same activity was "test fixtures," "test data setup," or "preconditions." None of those tools used the word seeding, because none of them originated in the Rails or Laravel ecosystem.
What changed is the tooling. Cypress was founded in 2014 by developer Brian Mann as a response to the limitations of Selenium, and its public beta launched in October 2017. Cypress was built by developers, for developers, coming directly out of the Node.js and Rails world. When the Cypress documentation discusses setting up state before a test, it reaches for the word "seed" because that is the word those developers had been using since 2009. Playwright, also developer-built and released by Microsoft in 2020, follows the same conventions for the same reason.
As JavaScript-based E2E tools replaced Selenium as the default choice for web automation, their vocabulary traveled with them into QA conversations. You are not encountering a new concept. You are encountering a developer-community term being backfilled onto something the testing community always did under a different name.
Why, thank you Claude! That was really helpful!
And, as always, Happy Testing!
-T.J. Maher
Software Engineer in Test
tjmaher.com | BlueSky | YouTube | LinkedIn | Articles
SOCIAL SHARE CARD GENERATOR