Comments on: Go Ahead. Break the Build!

By: airgle

airgle — Tue, 25 Sep 2007 14:03:19 +0000

The problem could also be solved by distinguishing between a staging area (prospective commit) and an actual build.

By: Andreq Swift

Andreq Swift — Mon, 06 Aug 2007 14:41:44 +0000

I agree.

Using TestNG groups is a great way of working around the build problems mentioned. It also gives you a chance to run only the
tests that are in the broken group so you can see your todo list in front of you

Allowing checkins of tests that fail is a must when doing Test driven development.

By: links for 2007-05-27 « betaalfa

links for 2007-05-27 « betaalfa — Sun, 27 May 2007 04:17:53 +0000

[...] Go Ahead. Break the Build! (tags: testing development ci maven junit agile by:elliotte_rusty_harold) [...]

By: Bill de hOra

Bill de hOra — Sat, 03 Feb 2007 17:09:49 +0000

Taking potshots at Charle’s Miller is unconvincing given Atlassian are making some of the best Java payware out there.

“The solution, perhaps, is the anti-test. Write a test that verifies the bug.”

Sounds like a plan to me, but making them go green is chromatic overloading. I would use another color for tests that verify a defect- black or purple maybe. Hey, can that feature ship for Bamboo 1.0!?

By: deployJava » Go Ahead. Break the Build!

deployJava » Go Ahead. Break the Build! — Tue, 30 Jan 2007 12:07:12 +0000

[...] Go… [...]

By: The Disco Blog » Blog Archive » The weekly bag– Jan 26

The Disco Blog » Blog Archive » The weekly bag– Jan 26 — Sat, 27 Jan 2007 02:26:08 +0000

[...] Go Ahead. Break the Build!- I agree in principle, but in practice it has dangers, man. [...]

By: Cedric

Cedric — Wed, 24 Jan 2007 05:37:07 +0000

Danno,

Groups are also a good solution for running tests only for certain platforms: you can put methods in a group “win32″, “macos”, “linux” or any combination thereof, and then only run these groups on the given platforms.

By: Cedric

Cedric — Wed, 24 Jan 2007 05:31:22 +0000

Tim,

Yes, it’s very easy to achieve with TestNG: you can put your test methods in a particular group (I use “broken”) and always exclude this group from your test runs. After each run, TestNG generates several HTML reports, one of which lists all the methods in each group, so it’s trivial to find out which test methods are currently being skipped and make sure they are removed from the “broken” group before you ship.

–
Cedric

By: Andy

Andy — Wed, 24 Jan 2007 03:29:56 +0000

I used to own a car that had an oil leak– it was a ridiculous EPA nightmare. When the roads were slick due to rain, there would be a visible oil slick following my car. I used to add a quart of oil to the engine every other day. After some time, I got lazy and wouldn’t even check the oil level before I added a quart. Later, I got even lazier and would forget to add oil for days– then one day while I was driving to work my engine block fused into a solid hunk of very hot metal. Amazingly enough, it didn’t blow up and kill me.

I had a failing unit test but I got lazy and stopped caring about it. It cost me ten grand to buy a new car (which I had to buy the next day so I could go to work and get paid). If I had fixed the issue when I noticed the leak (it was a gasket that needed replacing of all things) it would have maybe cost me a few hundred bucks.

I agree in principle to your point, but in practice it has the potential to lead to bad things (especially if people like me are watching over things!).

By: Dave

Dave — Wed, 17 Jan 2007 21:31:56 +0000

The problem could also be solved by distinguishing between a staging area (prospective commit) and an actual build (commit). I’ve worked on a lot of projects over many years, and introducing an official staging area was really a big help in a lot of ways.

By the way, developers who break the staging area builds get to clean up their own messes, too.