Patent Application
20120174068
This disclosure relates to testing software code and, more particularly, to testing particular software code that includes one or more dependencies on separate software code.
Software code, typically, is tested during and after development, as well as, for example, during development of upgrades to the code and other circumstances. Problems may often arise when testing code for a variety of reasons. For example, some software code that is to be tested (i.e., code under test (“CUT”)) often depends on other software code. This other code is often a component (e.g., production code to be shipped to a customer) on which the CUT depends, i.e., a depended on component, or “DOC.” These dependencies can often cause problems in testing the CUT. For instance, dependencies on objects or function modules may cause testing failures due to, for example, bugs in the objects or function modules themselves. As another example, dependencies on a database may cause testing problems (i.e., an inability to complete testing of the CUT) due to, for example, unexpected data in the database. Further, there may be unknown dependencies, which are required for the CUT to function (e.g., compile, execute or otherwise) correctly but which a developer is unaware.
Certain conventional techniques exist to help overcome these obstacles. For example, test doubles (“TD”), i.e., code that replaces a DOC and is only used for test purposes, may help enable testing of the CUT in isolation. As another example, dependency injection may be used. To make such CUT testable with these techniques, it may need to be reworked with high effort and risk due to changes in the production code. Thus, these techniques may not be attractive or available for many developers. Further, depending on, for example, the code language in which the CUT is written, such techniques may not fully overcome the aforementioned obstacles. Thus, additional techniques may be necessary to fully address these obstacles.
In one general embodiment, a computer-implemented method for testing software code includes the following steps performed by one or more processors: receiving a request to test at least a first portion of software code at a test framework, where the first portion of software code includes a dependency on a second portion of software code and, the request defines a test case to be executed at the test framework; marking the second portion of software code to indicate the dependency in the first portion of code; and replacing the second portion of software code with a third portion of software code during testing of the first portion of software code based on the marking of the second portion of software code.
In one or more specific aspects of this general embodiment, marking the second portion of software code to indicate the dependency in the first portion of code may include inserting one or more annotations in the first portion of software code.
In one or more specific aspects of this general embodiment, marking the second portion of software code to indicate the dependency in the first portion of code may include processing a selection of the second portion of software code in a development environment.
In one or more specific aspects of this general embodiment, marking the second portion of software code to indicate the dependency in the first portion of code may include processing at least one marker statement in the first portion of software code indicating the second portion of software code.
In one or more specific aspects of this general embodiment, replacing the third portion of software code in place of the second portion of software code during testing of the first portion of software code may include: identifying the third portion of software code based on a third statement in the software code indicating a beginning of the third portion of software code, which will be executed in place of the second portion of software code during testing of the first portion of software code; and processing a fourth statement in the software code indicating an end of the third portion of software code.
One or more specific aspects of this general embodiment may further include processing a second statement in the first portion of software code indicating an end of the second portion of software code.
In one or more specific aspects of this general embodiment, the second statement may include an endseam statement.
In one or more specific aspects of this general embodiment, the second portion of software code may include at least one of: a system field; an authority check; an object creation; a static method call; a file access; a function call; a database access; a data object; and a web service access.
In one or more specific aspects of this general embodiment, the first statement may include at least one of a marker or seam statement.
In one or more specific aspects of this general embodiment, the first portion of software code may include production code.
In one or more specific aspects of this general embodiment, the third portion of software code may include a first fragment of software code and a second fragment of software code. One or more specific aspects of this general embodiment may further include: replacing the second portion of software code with one or more of the first and second segments of software code during testing of the first portion of software code based on the marking of the second portion of software code.
In one or more specific aspects of this general embodiment, replacing the second portion of software code with one or more of the first and second segments of software code during testing of the first portion of software code based on the test case may include: determining one of the first segment or second segment of software code to replace the second portion of software code during testing of the first portion of software code based on the test case; and replacing the second portion of software code with the determined one of the first or second segments of software code during testing of the first portion of software.
In one or more specific aspects of this general embodiment, the second portion of software code may include a third fragment of software code and a fourth fragment of software code. One or more specific aspects of this general embodiment may further include: replacing one or more of the third and fourth fragments of software code with the third portion of software code during testing of the first portion of software code based on the test case.
In one or more specific aspects of this general embodiment, replacing one or more of the third and fourth fragments of software code with the third portion of software code during testing of the first portion of software code based on the test case may include: determining one of the third segment or fourth segment of software code to be replaced by the third portion of software code during testing of the first portion of software code based on the test case; and replacing the determined one of the third or fourth fragments of software code with the third portion of software code during testing of the first portion of software code.
In one or more specific aspects of this general embodiment, marking the second portion of software code to indicate the dependency in the first portion of code may further include specifying which of the third and fourth fragments of software code are to be replaced with the third portion of software code during testing of the first portion of software code.
In one or more specific aspects of this general embodiment, marking the second portion of software code to indicate the dependency in the first portion of code may further include triggering replacement of the second portion of software code with the third portion of software code during testing of the first portion of software code.
In one or more specific aspects of this general embodiment, the third statement may include at least one of: an inject statement; a call to an injection API; an inject annotation. In one or more specific aspects of this general embodiment, the third statement may also be expressed by meta data which is stored separately from the source code.
The present disclosure also provides a computer-readable, non-transitory storage medium coupled to one or more processors and having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with implementations of the methods provided herein.
The present disclosure further provides a system for implementing the methods provided herein. The system includes at least a server including one or more processors, and a computer-readable storage medium coupled to the one or more processors having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with implementations of the methods provided herein.
Various embodiments of and including a software test framework using test seams may include one or more of the following features or advantages. For example, a software test framework, which supports testing with test seams, may be useful in testing both object-oriented code, as well as code written in non-object oriented languages. For example, the software test framework may replace statements, rather than, for example, objects and/or classes. In addition, the software test framework may be used for development languages that are not purely object-oriented but, for example, contain function module calls and statements which are provided by libraries in other languages. As another example, the software test framework may test a CUT while eliminating all or substantially all problem-causing dependencies with relatively few (e.g., about five statements) changes to the CUT. Further, the software test framework using test seams may test a CUT while eliminating all or substantially all problem-causing dependencies in both legacy and newly developed code. The software test framework using test seams may test a CUT while eliminating all or substantially all problem-causing dependencies without changing the functionality of the original code in the CUT. In addition, the software test framework using test seams may surround any kind of statement so as to eliminate and/or substantially eliminate dependencies such as, for example, SY-fields (e.g., system field), authority checks, database access, remote function calls (RFC), object creation, static methods, function modules, file access, and web service access. As another example, the software test framework using test seams may test a CUT while eliminating all or substantially all problem-causing dependencies.
These general and specific aspects may be implemented using a device, system or method, or any combinations of devices, systems, or methods. Put differently, while generally described as computer implemented software that provides for test seams of software code to be tested, some or all of the aspects may be computer implemented methods or further included in respective systems or other devices for performing this described functionality. The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.
In general, server 102 is any server that stores one or more hosted applications 122, where at least a portion of the hosted applications 122 are executed via requests and responses sent to users or clients within and communicably coupled to the illustrated environment 100 of
At a high level, the server 102 comprises an electronic computing device operable to receive, transmit, process, store, or manage data and information associated with the environment 100. The server 102 illustrated in
As used in the present disclosure, the term “computer” is intended to encompass any suitable processing device. For example, although
In the illustrated implementation, and as shown in
In some implementations, the server 102 may also include a user interface, such as a graphical user interface (GUI) 160a. The GUI 160a comprises a graphical user interface operable to, for example, allow the user of the server 102 to interface with at least a portion of the platform for any suitable purpose, such as creating, preparing, requesting, or analyzing data, as well as viewing and accessing source documents associated with business transactions. Generally, the GUI 160a provides the particular user with an efficient and user-friendly presentation of business data provided by or communicated within the system. The GUI 160a may comprise a plurality of customizable frames or views having interactive fields, pull-down lists, buttons, and other controls operated by the user. For example, GUI 160a may provide interactive elements that allow a user to enter or select elements of business process instances in GUI 160a. More generally, GUI 160a may also provide general interactive elements that allow a user to access and utilize various services and functions of hosted applications 122. The GUI 160a is often configurable, supports a combination of tables and graphs (bar, line, pie, status dials, etc.), and is able to build real-time portals, where tabs are delineated by key characteristics (e.g. site or micro-site). Therefore, the GUI 160a contemplates any suitable graphical user interface, such as a combination of a generic web browser, intelligent engine, and command line interface (CLI) that processes information in the platform and efficiently presents the results to the user visually.
Generally, example server 102 may be communicably coupled with a network 112 that facilitates wireless or wireline communications between the components of the environment 100 (i.e., between the server 102 and client 135 as well as between servers 140 and 102 or workstations 170), as well as with any other local or remote computer, such as additional clients, servers, or other devices communicably coupled to network 112 but not illustrated in
As illustrated in
Regardless of the particular implementation, “software” may include computer-readable instructions, firmware, wired or programmed hardware, or any combination thereof on a tangible medium operable when executed to perform at least the processes and operations described herein. Indeed, each software component may be fully or partially written or described in any appropriate computer language including C, C++, Java, Visual Basic, assembler, Perl, any suitable version of 4GL, as well as others. It will be understood that while portions of the software illustrated in
At a high level, each of the one or more hosted applications 122 is any application, program, module, process, or other software that may execute, change, delete, generate, or otherwise manage information according to the present disclosure, particularly in response to and in connection with one or more requests received from the illustrated clients 135 and their associated client applications 144. In certain cases, only one hosted application 122 may be located at a particular server 102. In others, a plurality of related and/or unrelated hosted applications 122 may be stored at a single server 102, or located across a plurality of other servers 102, as well. In certain cases, environment 100 may implement a composite hosted application 122. For example, portions of the composite application may be implemented as Enterprise Java Beans (EJBs) or design-time components may have the ability to generate run-time implementations into different platforms, such as J2EE (Java 2 Platform, Enterprise Edition), ABAP (Advanced Business Application Programming) objects, or Microsoft's .NET, among others. Additionally, the hosted applications 122 may represent web-based applications accessed and executed by remote clients 135 or client applications 144 via the network 112 (e.g., through the Internet). Further, while illustrated as internal to server 102, one or more processes associated with a particular hosted application 122 may be stored, referenced, or executed remotely. For example, a portion of a particular hosted application 122 may be a web service associated with the application that is remotely called, while another portion of the hosted application 122 may be an interface object or agent bundled for processing at a remote client 135. Moreover, any or all of the hosted applications 122 may be a child or sub-module of another software module or enterprise application (not illustrated) without departing from the scope of this disclosure. Still further, portions of the hosted application 122 may be executed by a user working directly at server 102, as well as remotely at client 135.
As illustrated, processor 118 can also execute the software test framework 104 that may provide an environment and user interface for presenting to a user of client application 144 options for testing one or more portions of CUT, such as CUT 126 stored in memory 120. In some implementations, the software test framework 104 can be executed by a different processor or server external to server 102, such as by a server communicably coupled to server 102 through network 112. For example, the software test framework 104 may be provided as an on-demand service through a cloud computing network, as a web service accessible via network 112, or as a service provided on a dedicated server. The software test framework 104 can provide interfaces, modules, services, or metadata definitions that enable client application 144 to provide support for testing one or more portions of CUT 126 executed at server 102 or at a different server or workstation.
The software test framework 104, in some embodiments, may implement a systematic procedure to uncover defects at various stages of a development life cycle of CUT 126 or other software code to be tested. For example, the software test framework 104 provides various mechanisms for testing CUT 126 that includes one or more dependencies on other software code (depended on components, or DOC), such as DOC 124. These mechanisms are described in further detail below in connection with
In general, the server 102 also includes memory 120 for storing data and program instructions. Memory 120 may include any memory or database module and may take the form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. Memory 120 may store various objects or data, including classes, frameworks, applications, backup data, business objects, jobs, web pages, web page templates, database tables, repositories storing business and/or dynamic information, and any other appropriate information including any parameters, variables, algorithms, instructions, rules, constraints, or references thereto associated with the purposes of the server 102 and its one or more hosted applications 122.
Memory 120 may also store data objects, for example, all or portions of software code, such as software code (CUT) 126 to be tested by the software test framework 104. CUT 126 may be objects, classes, methods, function modules, or other software code that may be required to be tested by the software test framework 104 prior to, for instance, delivery to a client, customer, or other entity. For example, the CUT 126 may be retrieved from memory 120 when the software test framework 104 is executed or initiated to test the CUT 126 for errors or other irregularities. Although illustrated as a single portion of software code, CUT 126 may be multiple portions of code to be tested, separate segments or modules of code to be tested in a single data file, or any other combination of modules, segments, portions, or other instances of code to be tested. Further, CUT 126 may be written in any programming language, such as, for example, C++, C, Java, ABAP (Advanced Business Application Programming by SAP), Visual Basic, assembler, Perl, any suitable version of 4GL, as well as others.
Memory 120 may also store one or more depended on components (DOC) 124. DOC 124 may be objects, classes, methods, function modules, data stored in one or more databases or other repositories, software code that are separate from or a part of the CUT 126, or other components on which the CUT 126 depends. The DOC 124 may be retrieved from memory 120 during testing of the CUT 126 by the software test framework 104. For example, the DOC 124 may be a particular function module within a method (i.e., the CUT 126). In some embodiments, the software test framework 104 may not be able to control the behavior of the DOC 124 during testing of the CUT 126. Thus, the CUT 126 (i.e., the method) may not be able to be tested at all.
The illustrated environment of
The GUI 162 associated with client 135 comprises a graphical user interface operable to, for example, allow the user of client 135 to interface with at least a portion of the platform for any suitable purpose, such as creating, preparing, requesting, or analyzing data, as well as viewing and accessing source documents associated with business transactions. Generally, the GUI 162 provides the particular user with an efficient and user-friendly presentation of business data provided by or communicated within the system. The GUI 162 may comprise a plurality of customizable frames or views having interactive fields, pull-down lists, and buttons operated by the user. For example, GUI 162 may provide interactive elements that allow a user to enter or select elements of business process instances in GUI 162.
As used in this disclosure, client 135 is intended to encompass a personal computer, touch screen terminal, workstation, network computer, kiosk, wireless data port, smart phone, personal data assistant (PDA), one or more processors within these or other devices, or any other suitable processing device. For example, each client 135 may comprise a computer that includes an input device, such as a keypad, touch screen, mouse, or other device that can accept user information, and an output device that conveys information associated with the operation of the server 102 (and hosted application 122) or the client 135 itself, including digital data, visual information, the client application 144, or the GUI 162. Both the input and output device may include fixed or removable storage media such as a magnetic storage media, CD-ROM, or other suitable media to both receive input from and provide output to users of client 135 through the display, namely, the GUI 162.
The software test framework 104 (as well as the DOC 124 and CUT 126) may be presented and accessible to the user through GUI 162, such as through a web browser or other interface, for example. Thus, a developer utilizing client 135 and the GUI 162 may execute the test framework 104 on the server 102. Moreover, the present disclosure contemplates that the software test framework 104, as well as the DOC 124 and CUT 126, may be stored on and/or executable on the client 135. For example, all or portions of the DOC 124 and CUT 126 may be stored in memory 150. In some embodiments, all or portions of the DOC 124 may be stored separately from portions of the CUT 126; for instance, the DOC 124 may be stored in memory 120 while the CUT 126 may be stored in memory 150. Further, all or portions of the DOC 124 and CUT 126 may be stored in repositories separate from, but communicably coupled to, one or both of the server 102 and client 135.
While
Turning particularly to
Turning now to
Turning to
In some embodiments, statements inside the injection 260 may live inside the seam 220. Thus, in some embodiments, the scope of the injection 260 may be the scope of the processing block (e.g., method, function module, or otherwise) in which the seam 220 is defined. Further, in some embodiments, use of the seam 220 and/or the injection 260 may allow for the CUT 200 to be tested without changing the functionality of the CUT 200. Further, in some embodiments, seam 220 may be utilized to isolate any type of dependency defined in the DOC 205, such as, for example, SY-fields, Authority-Checks, Database Access, RFC calls, Object Creation, Static Methods, Function Modules, File Access, and other dependencies.
In some embodiments, the class 310 may be desired to be tested, i.e., may be a CUT to be tested by a software test framework such as framework 104. Further, it may be desirable to encapsulate function modules concerning currency conversion in the class 310 with a class and an interface (e.g., interface 315). Once encapsulated, and with the new interface and the new class in place, the CUT (i.e., the production code) may be changed. For example, the function module call may be replaced with a method call to the new interface. Turning to
Turning now to
In some embodiments, the techniques described with reference to
Turning now to method 550 illustrated in
During the execution of such test case, when the INJECT statement is processed, the replacement of the production code (i.e., the function module call or DOC) with the test code (converted_amount=1.5) may be triggered. During the next call of the CUT 600, the “injected” test code will be executed instead of the production code marked with the SEAM statement. When the next INJECT statement is processed, the first replacement will be reverted and the next one (converted_amount=2) may be “activated.” As an alternative example, a reference to the injected code may be used to inject the same portion in more than one test seam. Such injection in a test case may look like this: INJECT <name_of_injected_portion> INTO <name_of_SEAM>.
In addition, an injection in a test case may include other techniques alternative to the INJECT <name_of_injected_portion> INTO <name_of_SEAM> statement. For example, an injection can be triggered by a call to an application program interface (API), such as, for example: CL_API=>inject(name_of_injected_portion, name_of_SEAM). As another example, an injection can be triggered by an annotation, such as, for example: @INJECT(name_of_injected_portion, name_of_SEAM). Further, an injection may be made by meta data, i.e., content in a repository that may be used as a directive for a data-driven test framework to INJECT(name_of_injected_portion, name_of_SEAM).
A number of embodiments have been described. Nevertheless, it will be understood that various modifications may be made. For instance, the illustrated steps of methods 500 and 550 may be performed in different orders than those shown in
As another example, although illustrated in some portions of this disclosure as a single portion of software code, the DOC 124 (or other DOC) may consist of several, separate fragments of software code. Each segment, or fragment, of the DOC 124 may be treated separately. In other words, one or more of the fragments of the DOC 124 may be replaced during testing of the CUT 126. For example, a test framework may apply a test stub in place of the fragment of the DOC 124 during testing of the CUT 126. A determination of which fragment to replace may be made according to, for example, which fragment of the DOC 124 is more (or less) likely to cause a problem during exercising CUT 126 by a test case.
As yet another example, although illustrated in some portions of this disclosure as a single portion of software code, the injection 260 (or other injection) may consist of several, separate fragments of software code. Each segment, or fragment, of the injection 260 may be treated separately. In other words, one or more of the fragments of the injection 260 may be applied during testing of the CUT 126 in place of, for example, one or more portions of DOC 124. For example, a test framework may apply a particular fragment of the injection 260 during testing of the CUT 126. A determination of which fragment to apply may be made according to, for example, a test case. Accordingly, other embodiments are within the scope of the following claims.
