<?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.3/uma.ecore" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-VGT8iHGtQSiOUGitq1qmow" name=",_eRutgC5QEduVhuZHT5jKZQ" guid="-VGT8iHGtQSiOUGitq1qmow" changeDate="2006-12-28T10:50:35.593-0800" version="1.0.0">
  <mainDescription>&lt;p&gt;
    This guideline describes a number of types of tests. To perform these types of testing you need to define, and then
    run, a series of tests against&amp;nbsp;the source code. A developer test is a single test that needs to be performed.
&lt;/p&gt;
&lt;p&gt;
    It is valuable&amp;nbsp;to augment automated tests with human readable test scripts in order to implement developer test
    cases, scripts that include the information discussed below. A test script is the actual steps, sometimes either
    written procedures to follow or the source code of a test. Developer test scripts are run against testing targets:
    either one unit of source code, a more complex portion of your system (such as a component), or the entire system
    itself to test&amp;nbsp;some developer issue such as integration.
&lt;/p&gt;
&lt;h3&gt;
    Regression Testing
&lt;/h3&gt;
&lt;p&gt;
    Regression testing is the act of ensuring that changes to&amp;nbsp;the code have not adversely affected existing
    functionality. It is important to recognize that incremental development makes regression testing critical. Whenever
    you release an application, you must ensure its previous functionality still works, and because you release
    applications more often when taking the incremental approach, this means regression testing becomes that much more
    important. Regression testing is the first thing you should be thinking about when testing for the following reasons:
&lt;/p&gt;
&lt;ol&gt;
    &lt;li&gt;
        You want to be able to modify code and know that you can rerun your tests to see if you broke anything.
    &lt;/li&gt;
    &lt;li&gt;
        Existing users get very angry when things that previously worked don’t work anymore.
    &lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;
    Regression testing is fairly straightforward conceptually – you just need to run all of&amp;nbsp;the previous test cases
    against the new version of&amp;nbsp;the code. Regression testing tools help immensely because they are designed with
    regression testing in mind. However, there are potential challenges to regression testing:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        When you change your production, either to enhance it or to refactor it, you will need to rework existing test
        cases coupled to that code.
    &lt;/li&gt;
    &lt;li&gt;
        If your updates affect only a component of the system, then potentially you only need to run the test cases that
        affect this single component. Although this approach is a little risky because your changes may have had a greater
        impact than you suspect, it does help to reduce both the time and cost of regression testing.
    &lt;/li&gt;
    &lt;li&gt;
        The more non-code artifacts that you decide to keep, the greater the effort to regression test your work and
        therefore the greater the risk to your project because you are more likely to skimp on your testing efforts.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    Regression testing is critical to success as an agile developer. Many software developers use the xUnit family of open
    source tools, such as &lt;a href=&quot;http://www.junit.org/&quot; target=&quot;_blank&quot;&gt;JUnit&lt;/a&gt; and &lt;a href=&quot;http://www.vbunit.org/&quot;
    target=&quot;_blank&quot;&gt;VBUnit&lt;/a&gt;, to test their code. The advantage of these tools is that they implement a testing framework
    with which you can regression test all of your source code. Commercial testing tools are also viable options.
&lt;/p&gt;
&lt;h3&gt;
    Traditional Code Testing Techniques
&lt;/h3&gt;
&lt;p&gt;
    Although object and procedural technologies are different, several important testing concepts from the procedural world
    are valid regardless of the underlying technology. These traditional testing techniques are:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Black-box testing
    &lt;/li&gt;
    &lt;li&gt;
        Clear-box testing
    &lt;/li&gt;
    &lt;li&gt;
        Boundary-value testing
    &lt;/li&gt;
    &lt;li&gt;
        Coverage/Path testing
    &lt;/li&gt;
&lt;/ul&gt;
&lt;h4&gt;
    Black-Box Testing
&lt;/h4&gt;
&lt;p&gt;
    Black-box testing, also called interface testing, is a technique in which you create test cases based only on the
    expected functionality of a method, class, or application without any knowledge of its internal workings. One way to
    define black-box testing is that given input A you should obtain expected results B.
&lt;/p&gt;
&lt;p&gt;
    The goal of black-box testing is to ensure the system can do what it should be able to do, but not how it does it. For
    example, if you invoke differenceInDays(June 30 2006, July 3 2006) the expected result should be three. The creation of
    black-box tests is often driven by the requirements for&amp;nbsp;the system. The basic idea is&amp;nbsp;to look at the user
    requirement and ask what needs to be done to show that the user requirement is met.
&lt;/p&gt;
&lt;p&gt;
    The primary advantage of black-box testing is that it enables you to prove that your application fulfills the
    requirements defined for it.&amp;nbsp;&amp;nbsp; The primary disadvantage is that it does not show that the internals
    of&amp;nbsp;the system work (hence the need for clear-box testing).
&lt;/p&gt;
&lt;h4&gt;
    Clear-Box Testing
&lt;/h4&gt;
&lt;p&gt;
    Clear-box testing, also called white-box testing, is based on the idea that&amp;nbsp;the program code can drive the
    development of test cases. The basic concept is you look at&amp;nbsp;the code, and then create test cases that exercise it.
    For example, assume you have access to the source code for differenceInDays(). When you look at it, you see an IF
    statement determines whether the two dates are in the same year. If&amp;nbsp;they are in the same year then&amp;nbsp;a simple
    strategy based on Julian dates is used; if not then a more complex&amp;nbsp;strategy is used. This indicates that you need
    at least one test that uses dates from the same year and one from different years. By looking at the code, you are able
    to determine new test cases to exercise the different logic paths within it.
&lt;/p&gt;
&lt;p&gt;
    The primary advantage of this concept is that it motivates you to create tests that exercise specific lines of
    code.&amp;nbsp; The disadvantages are that it does not ensure that your code fulfils the actual requirements (hence the
    need for black-box testing) and that your testing code becomes highly coupled to your application code.
&lt;/p&gt;
&lt;h4&gt;
    Boundary-Value Testing
&lt;/h4&gt;
&lt;p&gt;
    This is based on the knowledge that you need to test your code to ensure it can handle unusual and extreme situations.
    For example, boundary-value test cases differenceInDays() would include passing it the same date, two wildly different
    dates, one date on the last day of the year and the second on the first day of the following year, and one date on
    February 29th of a leap year. The basic idea is you want to look for limits defined either by your business rules or by
    common sense, and then create test cases to test attribute values in and around those values.
&lt;/p&gt;
&lt;p&gt;
    The primary advantage of boundary value testing is that it motivates you to confirm that your program code is able to
    handle “unusual” or “extreme” cases.
&lt;/p&gt;
&lt;h4&gt;
    Coverage and Path Testing
&lt;/h4&gt;
&lt;p&gt;
    Two critical “traditional” concepts are coverage and path testing. Coverage testing is a technique in which you create
    a series of test cases designed to test all the code paths in your code. In many ways, coverage testing is simply a
    collection of clear-box test cases that together exercise every line of code in your application at least once. Path
    testing is a superset of coverage testing that ensures not only have all lines of code been tested, but all paths of
    logic have also been tested. The main difference occurs when you have a method with more than one set of case
    statements or nested IF statements: to determine the number of test cases with coverage testing you would count the
    maximum number of paths between the sets of case/nested IF statements and, with path testing, you would multiply the
    number of logic paths.
&lt;/p&gt;
&lt;h4&gt;
    Unit and Integration Testing
&lt;/h4&gt;
&lt;p&gt;
    Unit testing is the testing of an item, such as an operation, in isolation. For example, the tests defined so far for
    differenceInDays() are all unit tests. Integration testing, on the other hand, is the testing of a collection of items
    to validate that they work together. In the case of the data library/class, do the various functions work together?
    Perhaps the differenceInDays() function has a side effect that causes the dayOfWeek() function to fail if
    differenceInDays() is called first. Integration testing looks for problems like this.
&lt;/p&gt;
&lt;h3&gt;
    Object-Oriented Testing Techniques
&lt;/h3&gt;
&lt;p&gt;
    When testing systems built using object technology it is important to understand that your source code is composed of
    several constructs, including methods (operations), classes, and inheritance. Therefore you need testing techniques
    that reflect the fact that you have these constructs. These techniques are:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Method testing
    &lt;/li&gt;
    &lt;li&gt;
        Class testing
    &lt;/li&gt;
    &lt;li&gt;
        Class-integration testing
    &lt;/li&gt;
    &lt;li&gt;
        Inheritance-regression testing
    &lt;/li&gt;
&lt;/ul&gt;
&lt;h4&gt;
    Method Testing
&lt;/h4&gt;
&lt;p&gt;
    Method testing is the act of ensuring that your methods (operations) perform as defined. In procedural testing this
    would have been called function/procedure testing. Issues to address via method testing include:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Ensure that your getter/setter methods work as intended
    &lt;/li&gt;
    &lt;li&gt;
        Ensure that each method returns the proper values, including error messages and exceptions
    &lt;/li&gt;
    &lt;li&gt;
        Validate the parameters being passed to a method
    &lt;/li&gt;
    &lt;li&gt;
        Ensure that a method does what it should
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    The advantage of method testing is that it ensures that methods work well in isolation but it does not help to find
    unintended side effects.
&lt;/p&gt;
&lt;h4&gt;
    Class Testing
&lt;/h4&gt;
&lt;p&gt;
    The main purpose of class testing is to test classes in isolation, and it is effectively the combination of traditional
    unit testing and integration testing. It is unit testing because you are testing the class and its instances as single
    units in isolation, but it is also integration testing because you need to verify the methods and attributes of the
    class work together. The one assumption you need to make while writing “class tests” is that all other classes in the
    system work. Issues to address via class testing include:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Validate that the attributes of an object are initialized properly
    &lt;/li&gt;
    &lt;li&gt;
        Validate the invariants of the class
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    The primary advantages of class testing are that it validates that the operations and properties of a class work
    together and that the class works in isolation. However, it does not guarantee that a class works well with the rest of
    your system.
&lt;/p&gt;
&lt;h4&gt;
    Class-integration Testing
&lt;/h4&gt;
&lt;p&gt;
    Also known as component testing, this technique addresses the issue of whether the classes in your system, or a
    component of your system, work together properly. The relationships between classes can be used to drive the
    development of class integration test cases. Issues to address via class-integration testing include:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Validate that objects do what other objects expect of them
    &lt;/li&gt;
    &lt;li&gt;
        Validate that return values are acted appropriately
    &lt;/li&gt;
    &lt;li&gt;
        Validate that exceptions/errors are processed appropriately
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    The technique helps to validate that the various classes within a component, or a system, work together. However, it
    can be difficult to define and develop the test cases to fully perform this level of testing.
&lt;/p&gt;
&lt;h4&gt;
    Inheritance-regression&amp;nbsp;Testing
&lt;/h4&gt;
This is the act of running of test cases defined for the superclasses on the instances of a subclass because errors have
not been introduced by that new subclass. New methods are added and existing methods may be redefined by subclasses,
methods which access and potentially change the value of the attributes defined in the superclass. It is possible that a
subclass may change the value of the attributes in a way that was never intended in the superclass, or at least was never
expected. The point is that you need to invoke the test suite of the superclass(es) when testing a subclass. &lt;br /&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>