Every software project is different and requires its own test strategy and the right mix of different types of tests. The best tests, however, are of little use if it's not clear what has actually been tested. This necessary transparency can be provided by UWS in using different test metrics which analyse the code-coverage of written test. UWS test environments provide transparency beginning with the actual requirement up to the code and its amendments.
Test-driven development, model-driven and automatic test generation, fast executable unit testing by the developer, continuously performed integration testing and functional tests as well as the continuous automated detection and perception of test metrics provide our developers with confidence and courage. Courage for example to restructuring at the code level, the so-called refactoring. Because software is growing steadily, not executed refactoring leads to error-prone, and poorly maintainable and testable code. Different granularities of tests give developers quick feedback about where and how the code changes. Any errors are found quickly and can be corrected early.
Tests are communication, a tool for the developer to formulate assumptions and for each assumption, our developers know the right kind of test.
Unit testing is a method by which individual units or modules of source code can be tested along with test data towards a particular behavior. With a unit test the developer can then formulate a specific, expected behavior of a module. Modules are components of programs such as functions, methods, interfaces, classes or closures.
The developer is programming the unit tests independently, so that the sequence of execution does not matter. He is also testing only the specific module and replaces direct and indirect dependencies by so-called mock objects or fakes. Thus, a module can be tested in isolation.
Frameworks such as JUnit, TestNG, Spring-Testing, Mockito or EasyMock assist us in creating test cases make writing tests so easy that many of our developers execute test-driven development. In Test-Driven Development (TDD), tests are written before implementation resulting in a significant improvement with respect to modularization and test coverage, without causing significant overhead.
Integration testing is a method in which individual modules are tested in combination with each other as a composite. Integration tests are therefore carried out after the unit testing.
Integration tests assume that modules are so called "black boxes", this means that no details about the implementation can be found in this tests. Therefore, implementation-independent interfaces are tested against factors such as function, error handling, performance and reliability.
Functional testing or acceptance testing are methods to test end user functionality. Often, but not necessarily be functional tests defined by a requirements specification. UWS provides environments where functional tests can be created by non-technical team members within the project. Thus, for example future users of the software can create functional tests simply by clicking them together. This leads to a clear specification of the project, reduction of total test effort and executable specifications.
Test metrics like code coverage provide information about to what extend the source code is used for running tests. The test coverage can be traced back to the lines of code, so that detailed analyzes are possible, and questions can be answered:
Test- and code metrics are determined automatically by UWS test environments and are communicated primarily to the developers so that they anticipate potential failures and risks even before they arise.
Do you have questions about this subject? Soeren is available for your questions.