Writing a test that you know will fail until the bug is fixed is a good idea, its the basis of TDD.

Breaking the build is a bad idea. Why? Because it means that nothing can move on until it is fixed. It essentially blocks all other aspects of development.

**Example 1** 
What if your application is vary large, with many components? What if those components are worked on by other teams with their own release cycle? Tough! They have to wait for your bug fix!

**Example 2** 
What if the first bug is hard to fix and you find *another* bug with a higher priority? Do you also break the build for the second bug? Now you can't build until *both* are fixed. You have created an artificial dependency.

There is no logical reason why failing a test should stop a build. This is a decision that the dev team needs to make (perhaps with management discussion) weighing up the pros and cons of releasing a build with known bugs. This is very common in software development, pretty much all major software is releasef with at least *some* known issues.