The team can code and store the tests in projects within the solution, like the normal source code projects. These test projects are designed to provide a container to hold all tests. This interpretation offers tests the same functionalities as the source project receive of VSTS. For example, the tests are placed in the source code control, can be linked to work items, and the test results are saved on the foundation server for other team members to review.
STATIC CODE ANALYZER
The quality of the system’s source code depends on various aspects. One of these aspects is that the code is written inline with general code rules. Team members have to write their code in the same way with the same rules to create a common way to implement the system. Reviewing and ensuring that all the source code respects the coding agreements of the team or system development organization is hard to do.
VSTS has a functionality that enables the team members to validate their source code automatically to general coding rules or company specific coding rules. This static code analyzer finds errors in the code before it is compiled. It has a range of checks: from style to code correctness to security issues to validate the consistency of the implemented source code, as presented in the figure below.
The static code analyzer enables the team to import or create own validation rules. The analyzer is also customizable on which checks or rules to include in the analysis, whether to report as error or warning to set the severity of the inconsequentialities, and supports the creations of own rules and checks. All together increases the quality of the code as it is written in a common and consistent way.
CODE PROFILER
Code profiling is the process of finding the bottlenecks and roadblocks of the application as an executable version. This functionality of the VSTS for developers has the purpose to enable developers to measure the performance of an executable application and identify issues in the source code.
The developer has the ability to analyze the time and memory spends of the application, like identifying which methods or classes are using most of the execution time. After the code profiler reports its finding, as shown in the figure below, the developer is able to prioritize which parts of the source code needs to be optimized first, and which not to spend his time on.
UNIT TESTING
After implementing the first method into the source code of the system, the developer and/or tester has the opportunity to test its correctness by creating a unit test. A unit test is a functional class method test by calling a method with the appropriate parameters, exercise it and compare the results with the expected outcome to ensure the correctness of the implemented code.
A unit testing functionality is built in VSTS, which enables the team to write and run units tests. This way of testing the system creates an overlap of tasks and knowledge of the developer and the tester role, because the tests are written using the same code as the actual system source code. Normally, these unit tests are integrated in the system solution as a project and just like the source code of the system, the unit testing code is stored onto the team foundation server.
VSTS has the functionality to automatically generate unit test methods during the implementation of the system class methods. Note that, VSTS creates classes with test-methods and initiates variables, but the project team needs to refine these methods to be useful tests. Below figure shows the generated unit test for validating the “Add”- method of the calculator example.
The generated code has to be revised to be a functional unit test for the “add”-method.
VSTS attends the user that variable a, b and expected has to be initialized to an appropriate value. For example a is set on 20, b on 44 and expected on 64. If the actual implemented method does not match the expected value, this test method will alert the user with the error “CalcLogic.Calculator.Add did not return the expected value”. Note that, VSTS adds the last code line to inform the user that this unit test is not revised and may not be correct.
Recent Comments