Microsoft Technology Licensing, LLC

Manish Kumar Jayaswal

John Lawrence Hamby

Aleksey V Tsingauz

Tomas Matousek

Andrew Casey

Gen Lu

Ghanashyam Chandrasekhar Namboodiripad

Kevin Wagner Halverson

Artur Zbigniew Spychaj

En-Shuo Hsu

Peter Bern Waldschmidt

John Austin Fleisher

Tanner Evan Gooding

Instrumentation is extensible because the language construct to be instrumented and the particular instrumentation desired for the language construct can be provided to the compiler for each individual compilation using input provided during compilation of a program using a dynamic analyzer. The dynamic analyzer can identify the programming language construct to be instrumented and the instrumentation to be inserted into the code. The dynamic analyzer can analyze the data that is collected.

Extensible instrumentation

A compiler can instrument a program during the front end of compilation to collect data about runtime behavior when the program is executed. Instrumentation can occur during source language processing rather than later in the compilation chain. The instrumentation can occur in between semantic analysis and code generation. The instrumentation can occur in an instrumenting rewriting phase. The instrumentation can occur in a first lowering phase in which high level constructs in a programming language are rewritten as lower level constructs in intermediate representation (IR). The compiler can inject the instrumentation code at particular points in the source code based on specified language constructs in the source program. The types of instrumentation injected can be extended by providing additional information to the compiler at compilation time, without the need to reprogram the compiler.

Instrumenting program code

A computer device is provided that includes a display and a processor configured to execute an integrated development environment that includes a unit testing system configured to manage a plurality of unit tests for a set of code files. The processor is further configured to determine that a user is preparing to make a change to version control for the set of code files, retrieve test result data for one or more unit tests covering one or more code files of the set of code files that have been changed in the change to version control, and output the test result data on the display before completing the change to version control for the set of code files.

Unit testing for changes to version control

Metadata tables can provide the link between the instrumentation information collected and the location in the source code of the programming language construct that was instrumented. The metadata tables enable the relationship between the programming construct in the source code and the dynamic analysis information collected to be exact rather than an estimate. During compilation information is collected that enables a mapping between document table and analysis table to occur.

Mapping dynamic analysis data to source code

A computing device is provided, including a display and a processor. The processor may be configured to execute a source code authoring application program. The processor may be further configured to output a graphical user interface (GUI) of the source code authoring application program for display on the display. The processor may be further configured to receive source code including one or more code instructions at an editor window included in the GUI. The editor window may provide real-time mark-up of the source code. At a compiler platform, the processor may be further configured to determine that the source code includes at least one test method based on at least one syntactic test method indicator or symbolic test method indicator included in the source code. The processor may be further configured to output a notification of the at least one test method for display on the display.

Compiler platform for test method

Tools and techniques are described to detect possible holes in automated testing of software under development. Full line coverage by tests does not necessarily indicate actual coverage of execution scenarios, e.g., condition coverage, decision coverage, and other kinds of execution scenario coverage may be lacking even when all source code statements are nominally covered. When source code changes are submitted, and corresponding test-sets remain unchanged, users are notified that adequate testing is not assured by the current test-set. Testing assurance code in a development tool chain may flag a pull request, test-set, or source code submission to indicate a lack of testing assurance. In some cases, an assurance-enhanced tool may require that new or different tests be provided with updated source code as a prerequisite for that source code to be accepted for inclusion in a repository or a build, for example.

Growing community of inventors

Redmond, WA, United States of America

Manish Kumar Jayaswal