Combined the text in this element with the practice page, as there were redundancies between the two.
diff --git a/libraries/EPF_Practices_Library/practice.tech.test_driven_development.base/guidances/concepts/test_driven_development.xmi b/libraries/EPF_Practices_Library/practice.tech.test_driven_development.base/guidances/concepts/test_driven_development.xmi
deleted file mode 100644
index f5330ef..0000000
--- a/libraries/EPF_Practices_Library/practice.tech.test_driven_development.base/guidances/concepts/test_driven_development.xmi
+++ /dev/null
@@ -1,62 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<org.eclipse.epf.uma:ContentDescription xmi:version="2.0"
- xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore"
- xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmlns:rmc="http://www.ibm.com/rmc"
- rmc:version="7.2.0" xmi:id="-1ydZfAL3PacfKwqzAF6hUw"
- name="test_driven_development,_aI-NgJ04EdyQ3oTO93enUw" guid="-1ydZfAL3PacfKwqzAF6hUw"
- changeDate="2007-11-27T14:32:00.173-0800">
- <mainDescription><p>
- Test driven development&nbsp;is the practice of writing&nbsp;developer tests and&nbsp;implementation code concurrently
- and at a very fine level of granularity.
-</p>
-<p>
- In&nbsp;test driven&nbsp;design, the developer first writes a small portion of a&nbsp;developer test, and then writes
- just enough&nbsp;implementation code to make that&nbsp;developer test compile and execute. Then they write a little bit
- more of the test and then add enough code to make that new bit compile and pass. This cycle can last somewhere between
- 30 seconds and five minutes. Rarely does it grow to ten minutes. In each cycle, the tests come first. Once a unit test
- is done, the&nbsp;developer goes on to the next test until there are no more tests to be written for the implementation
- of the work item currently under development.
-</p>
-<p>
- The practice of test driven development changes how&nbsp;the developer&nbsp;thinks. Tests are not written as an
- afterthought. Instead, developer tests are written as part of the everyday, every minute way of building software.
-</p>
-<p>
- What are&nbsp;the advantages of test driven design?
-</p>
-<ol>
- <li>
- Assumptions in the design are analyzed before the implementation code is written. To write developer tests, an
- examination must be made of the behavior of each piece of code to be written, correct and incorrect behaviors must
- be defined. In&nbsp;a way, writing the tests before the code can be considered a version of detailed design.
- </li>
- <li>
- Code units designed&nbsp;for testability up front are cleaner and more loosely coupled.
- </li>
- <li>
- Errors&nbsp;are found earlier. Errors or gaps in the requirements and design are identified before coding begins
- when it could be more tempting to move ahead based on assumptions.
- </li>
- <li>
- A clearer&nbsp;collaboration strategy between the developer and others that might be responsible for the
- requirements, architecture, and design is put in place.&nbsp;During the creation of the tests, there must be a
- meeting of the minds as to what&nbsp;has been specified. After that, the implementation can carry on with
- confidence that there is a shared vision of what the code should do.
- </li>
- <li>
- There are unambiguous criteria for completion of the code. When the tests pass, the code is working as specified.
- Non-functional quality dimensions can be dealt with separately, but there is a clear moment when the code behaves
- correctly.
- </li>
- <li>
- The technique drives the developer to work in smaller increments with faster quality feedback. At any time the
- developer is just one test away from having error-free code.
- </li>
- <li>
- There is a separation of concerns and effort between getting code working and improving the quality of the code
- that already runs correctly. Separating out these two areas of concern provides focus and time management support
- to a developer who in one pass over the implementation makes it pass the tests as simply as possible and then in a
- subsequent pass, looks for areas to improve.
- </li>
-</ol></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
