--- title: "Tests and Builds are Made to be Broken" url: "https://osherove.com/blog/2013/1/20/tests-and-builds-are-made-to-be-broken.md" canonical: "https://osherove.com/blog/2013/1/20/tests-and-builds-are-made-to-be-broken.html" published: "2013-01-20T21:29:35" updated: "2013-01-20T21:29:35" tags: ["Build Bullet"] author: "Roy Osherove" description: "Many agile teams seem to be very focused on not breaking the build. I myself used to jokingly say that your team should have a “I Broke the Build” T-Shirt, to switch between team members. That was a mistake. I think…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Tests and Builds are Made to be Broken By Roy Osherove January 20, 2013 In [Build Bullet](https://osherove.com/blog/category/build-bullet) **Historical article** · Originally published January 20, 2013; technical details may be outdated. Many agile teams seem to be very focused on not breaking the build. I myself used to jokingly say that your team should have a “I Broke the Build” T-Shirt, to switch between team members. That was a mistake. I think that builds, much like tests, are made to be broken. Avoiding the public build is like debugging so you won’t have to run your tests. Well ,that last sentence is a bit of hyperbole. It’s like running your tests locally before running them on the build server. Which is actually a great thing to do, unless you can only run some of the tests locally, or it takes time to set up all the integration tests to run on your machine etc.. then it’s just a waste of time. Just run them in the build process. that’s what it’s for. As time goes on, I see many team members wasting precious time trying to avoid the build, by running it privately, when the whole purpose of the build was to give the indication of failure. > If the build never breaks, why have it in the first place? interesting bit on pre-tested commits [osherove.com/blog/2013/1/20…](http://t.co/06xgk0Ss "/blog/2013/1/20/build-pattern-gated-commit.html") > > — Ken Egozi (@kenegozi) [January 20, 2013](https://twitter.com/kenegozi/status/293073679884107777) I want to bring forward a small comment I made next to the “[Gated Commits](https://osherove.com/blog/2013/1/20/build-pattern-gated-commit.html)” build pattern I wrote about and that will end up in my [Beautiful Builds Booklet](http://beautifulbuilds.com/): This\[[pre-tested commits](https://osherove.com/blog/2013/1/20/build-pattern-gated-commit.html)\] can lead to an overall feeling in the team that breaking the build is wrong, and is to be avoided at any cost. This might not be a healthy attitude, since the original purpose of a build process was always to find out problems. You might say that if the build breaks, then the build did it’s job. If the build never breaks, why have it in the first place? ### The Blame Game: This culture of “breaking the build is bad, and it’s your fault” can lead to developers hiding their efforts, in an effort not to look stupid in front of their peers. in essence, a private build can lead to moving from a group effort, into individual based comparison system “who breaks the build the most?”. ### Lost Productivity: More problematic: if developers always get the build failing **privately**, developers will feel they have to **solve** the build privately. when the build fails publicly, it can trigger help from the rest of the team to solve the problem faster since more brains are involved. What about making all the other team members wait to commit until the build finally passes? Isn’t that lost productivity? theoretically, yes. but it also is a great reason for the team to help out and make the build pass. It is a “Stop the line” mentality, which we like to adopt in lean circles. Thoughts? ## Lessons on this topic - [Continuous Delivery](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/continuous-delivery/) · The Art of Unit Testing and TDD in Java - [Continuous Delivery with TeamCity](https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/continuous-delivery-with-teamcity/) · TDD and BDD in Ruby ## More in Build Bullet [All posts in Build Bullet](https://osherove.com/blog/category/build-bullet) - Apr 22, 2013 ### [Beautiful Builds: Release Compilation Step](https://osherove.com/blog/2013/4/23/beautiful-builds-release-compilation-step.html) - Feb 7, 2013 ### [Build Pattern: Cumulative Build](https://osherove.com/blog/2013/2/7/build-pattern-adopt-artifacts.html) - Jan 20, 2013 ### [Build Pattern: Gated Commit](https://osherove.com/blog/2013/1/20/build-pattern-gated-commit.html) - Jan 19, 2013 ### [Build Pattern: Extract Script](https://osherove.com/blog/2013/1/19/build-pattern-extract-script.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/