Modifiers that customize presentation of tested values to constraints

A device receives code generated via a technical computing environment (TCE), the code including a value to be tested, and receives a value modifier, a test case, and a constraint. The value modifier customizes a manner in which the value of the code is presented to the constraint for verification. The device also generates a test based on the value modifier, the test case, and the constraint, performs the test on the value of the code to generate a result, and outputs or stores the result.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more implementations and, together with the description, explain these implementations. In the drawings:

FIG. 1is a diagram of an overview of an example implementation described herein;

FIG. 2is a diagram of an example environment in which systems and/or methods described herein may be implemented;

FIG. 3is a diagram of example components of one or more of the devices of the environment depicted inFIG. 2;

FIG. 4is a diagram of example functional components of a technical computing environment (TCE) that may be used by one or more of the devices of the environment depicted inFIG. 2;

FIG. 5is a diagram of example operations capable of being performed by the TCE;

FIG. 6is a diagram of example functional components of a testing component of the TCE;

FIG. 7is a diagram of example operations capable of being performed by the testing component;

FIG. 8is a diagram of further example operations capable of being performed by the testing component; and

FIGS. 9 and 10are flow charts of an example process for providing modifiers that customize presentation of tested values to constraints.

DETAILED DESCRIPTION

A technical computing environment (TCE) may provide a computing environment that allows users to perform tasks related to disciplines, such as, but not limited to, mathematics, science, engineering, medicine, business, etc., more efficiently than if the tasks were performed in another type of computing environment, such as an environment that requires the user to develop code in a conventional programming language, such as C++, C, Fortran, Pascal, etc. In one example, a TCE may include a dynamically-typed programming language (e.g., the M language, a MATLAB® language, a MATLAB-compatible language, a MATLAB-like language, etc.) that can be used to express problems and/or solutions in mathematical notations.

Code generated by the TCE may be tested to determine whether the code will function properly (e.g., when executed). In a simple example, the code may be tested to determine whether a value in the code satisfies a constraint (e.g., is equal to a particular number). If the value satisfies the constraint (i.e., passes), diagnostic information may be generated that informs a programmer that the code functions properly. If the value does not satisfy the constraint (i.e., fails), diagnostic information may be generated that informs the programmer that the code does not function properly.

OVERVIEW

Systems and/or methods described herein may provide modifiers that customize a manner in which a tested value of code is presented to a test constraint for verification. A constraint may include a formal and literate description of what characteristics a tested value should possess. For example, a constraint (e.g., IsEqualTo(5)) may be applied to a tested value (e.g., actual_value), via syntax (e.g., verifyThat(actual_value, IsEqualTo(5))), to determine whether the tested value is equal to five. In this example, the tested value may be presented to the constraint as the tested value appears in the code. The systems and/or methods may provide a modifier that wraps the tested value and presents the tested value to the constraint in a different manner. For example, if the IsEqualTo(5) constraint is used and the actual_value is an array of elements, the constraint may be satisfied when only one of the elements of the array is equal to five. The systems and/or methods may provide a modifier (e.g., AnyElementOf) that enables the determination of whether any element of the actual_value array satisfies the IsEqualTo(5) constraint, according to the following syntax: verify(AnyElementOf(actual_value), IsEqualTo(5)).

FIG. 1is a diagram of an overview of an example implementation described herein. As shown inFIG. 1, a computing environment, such as a technical computing environment (TCE), may include a testing component. The testing component may receive code generated by the TCE, and may test the code to determine whether the code will function properly.

As further shown inFIG. 1, the testing component may receive code generated by the TCE. The TCE code may include text-based code that may require further processing to execute, binary code that may be executed, text files that may be executed in conjunction with other executables, etc. In one example, the TCE code may include one or more calculated values (e.g., actual_value) that may be tested by the testing component.

The testing component may receive a value modifier, a test case, and a constraint from a person testing (e.g., a tester) the TCE code. The value modifier may include a mechanism that wraps the tested value (e.g., actual_value) and presents the tested value to the constraint in a different manner. For example, the value modifier (e.g., AnyElementOf) may enable the determination of whether any element of the tested value satisfies the constraint. The test case may include syntax (e.g., verifyThat) to determine whether the tested value satisfies the constraint. The constraint may include a formal and literate description of what characteristics the tested value should possess. For example, the constraint (e.g., IsEqualTo(5)) may be applied to the tested value to determine whether the tested value is equal to five.

The testing component may generate a test for the TCE code based on the value modifier, the test case, and the constraint. In one example implementation, the testing component may combine the value modifier, the test case, and the constraint to create a test application programming interface (API), and may generate the test based on the test API. The testing component may perform the test on the TCE code to generate a result. In one example, the result may include diagnostic information (e.g., “At least one element of actual_value satisfies the IsEqualTo constraint.”). The testing component may output (e.g., display to the tester) and/or may store the result.

The terms “code” and “program code,” as used herein, are to be used interchangeably and are to be broadly interpreted to include text-based code that may not require further processing to execute (e.g., C++ code, Hardware Description Language (HDL) code, very-high-speed integrated circuits (VHSIC) HDL(VHDL) code, Verilog, Java, and/or other types of hardware or software based code that may be compiled and/or synthesized); binary code that may be executed (e.g., executable files that may directly be executed by an operating system, bitstream files that can be used to configure a field programmable gate array (FPGA), Java byte code, object files combined together with linker directives, source code, makefiles, etc.); text files that may be executed in conjunction with other executables (e.g., Python text files, a collection of dynamic-link library (DLL) files with text-based combining, configuration information that connects pre-compiled modules, an extensible markup language (XML) file describing module linkage, etc.); etc. In one example, code may include different combinations of the above-identified classes (e.g., text-based code, binary code, text files, etc.). Alternatively, or additionally, code may include code generated using a dynamically-typed programming language (e.g., the M language, a MATLAB® language, a MATLAB-compatible language, a MATLAB-like language, etc.) that can be used to express problems and/or solutions in mathematical notations. Alternatively, or additionally, code may be of any type, such as function, script, object, etc., and a portion of code may include one or more characters, lines, etc. of the code.

Example Environment Arrangement

FIG. 2is a diagram of an example environment200in which systems and/or methods described herein may be implemented. As illustrated, environment200may include a client device210interconnected with a server device220via a network230. Components of environment200may interconnect via wired and/or wireless connections. A single client device210, server device220, and network230have been illustrated inFIG. 2for simplicity. In practice, environment200may include more client devices210, server devices220, and/or networks230. In one example implementation, client device210and server device220may be provided in a single device or may be provided in separate devices.

Client device210may include one or more devices that are capable of communicating with server device220via network230. For example, client device210may include a laptop computer, a personal computer, a tablet computer, a desktop computer, a workstation computer, a smart phone, a personal digital assistant (PDA), and/or other computation and communication devices.

Server device220may include one or more server devices, or other types of computation and communication devices, that gather, process, and/or provide information in a manner described herein. Server device220may include a device that is capable of communicating with client device210(e.g., via network230). In one example, server device220may include one or more laptop computers, personal computers, workstation computers, servers, central processing units (CPUs), graphical processing units (GPUs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), etc. and/or software (e.g., a simulator) executing on the aforementioned devices. In one example, server device220may include TCE240and may perform some or all of the functionality described herein for client device210. Alternatively, server device220may be omitted and client device210may perform all of the functionality described herein for client device210.

Network230may include a network, such as a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network, such as the Public Switched Telephone Network (PSTN), an intranet, the Internet, or a combination of networks.

TCE240may be provided within a computer-readable medium of client device210. Alternatively, or additionally, TCE240may be provided in another device (e.g., server device220) that is accessible by client device210. TCE240may include hardware or a combination of hardware and software that provides a computing environment that allows users to perform tasks related to disciplines, such as, but not limited to, mathematics, science, engineering, medicine, business, etc., more efficiently than if the tasks were performed in another type of computing environment, such as an environment that required the user to develop code in a conventional programming language, such as C++, C, Fortran, Pascal, etc. In one implementation, TCE240may include a dynamically-typed programming language (e.g., the M language, a MATLAB® language, a MATLAB-compatible language, a MATLAB-like language, etc.) that can be used to express problems and/or solutions in mathematical notations.

For example, TCE240may use an array as a basic element, where the array may not require dimensioning. These arrays may be used to support array-based programming where an operation may apply to an entire set of values included in the arrays. Array-based programming may allow array-based operations to be treated as high-level programming that may allow, for example, operations to be performed on entire aggregations of data without having to resort to explicit loops of individual non-array operations. In addition, TCE240may be adapted to perform matrix and/or vector formulations that can be used for data analysis, data visualization, application development, simulation, modeling, algorithm development, etc. These matrix and/or vector formulations may be used in many areas, such as statistics, image processing, signal processing, control design, life sciences modeling, discrete event analysis and/or design, state based analysis and/or design, etc.

TCE240may further provide mathematical functions and/or graphical tools (e.g., for creating plots, surfaces, images, volumetric representations, etc.). In one implementation, TCE240may provide these functions and/or tools using toolboxes (e.g., toolboxes for signal processing, image processing, data plotting, parallel processing, etc.). Alternatively, or additionally, TCE240may provide these functions as block sets or in another way, such as via a library, etc.

TCE240may be implemented as a text-based environment (e.g., MATLAB software; Octave; Python; Comsol Script; MATRIXx from National Instruments; Mathematica from Wolfram Research, Inc.; Mathcad from Mathsoft Engineering & Education Inc.; Maple from Maplesoft; Extend from Imagine That Inc.; Scilab from The French Institution for Research in Computer Science and Control (INRIA); Virtuoso from Cadence; Modelica or Dymola from Dynasim; etc.); a graphically-based environment (e.g., Simulink® software, Stateflow® software, SimEvents® software, Simscape™ software, etc., by The MathWorks, Inc.; VisSim by Visual Solutions; LabView® by National Instruments; Dymola by Dynasim; SoftWIRE by Measurement Computing; WiT by DALSA Coreco; VEE Pro or SystemVue by Agilent; Vision Program Manager from PPT Vision; Khoros from Khoral Research; Gedae by Gedae, Inc.; Scicos from (INRIA); Virtuoso from Cadence; Rational Rose from IBM; Rhopsody or Tau from Telelogic; Ptolemy from the University of California at Berkeley; aspects of a Unified Modeling Language (UML) or SysML environment; etc.); or another type of environment, such as a hybrid environment that includes one or more of the above-referenced text-based environments and one or more of the above-referenced graphically-based environments.

TCE240may include a programming language (e.g., the MATLAB language) that may be used to express problems and/or solutions in mathematical notations. The programming language may be dynamically typed and/or array-based. In a dynamically typed array-based computing language, data may be contained in arrays and data types of the data may be determined (e.g., assigned) at program execution time.

For example, suppose a program, written in a dynamically typed array-based computing language, includes the following statements:A=‘hello’A=int32([1, 2])A=[1.1, 2.2, 3.3].

Now suppose the program is executed, for example, in a TCE, such as TCE240. During run-time, when the statement “A=‘hello”’ is executed the data type of variable “A” may be a string data type. Later when the statement “A=int32([1, 2])” is executed the data type of variable “A” may be a 1-by-2 array containing elements whose data type are 32 bit integers. Later, when the statement “A=[1.1, 2.2, 3.3]” is executed, since the language is dynamically typed, the data type of variable “A” may be changed from the above 1-by-2 array to a 1-by-3 array containing elements whose data types are floating point. As can be seen by this example, data in a program written in a dynamically typed array-based computing language may be contained in an array. Moreover, the data type of the data may be determined during execution of the program. Thus, in a dynamically type array-based computing language, data may be represented by arrays and data types of data may be determined at run-time.

TCE240may provide mathematical routines and a high-level programming language suitable for non-professional programmers and may provide graphical tools that may be used for creating plots, surfaces, images, volumetric representations, or other representations. TCE240may provide these routines and/or tools using toolboxes (e.g., toolboxes for signal processing, image processing, data plotting, parallel processing, etc.). TCE240may also provide these routines in other ways, such as, for example, via a library, local or remote database (e.g., a database operating in a computing cloud), remote procedure calls (RPCs), and/or an application programming interface (API). TCE240may be configured to improve runtime performance when performing computing operations. For example, TCE240may include a just-in-time (JIT) compiler.

AlthoughFIG. 2shows example components of environment200, in other implementations, environment200may include fewer components, different components, differently arranged components, and/or additional components than those depicted inFIG. 2. Alternatively, or additionally, one or more components of environment200may perform one or more other tasks described as being performed by one or more other components of environment200.

Example Device Architecture

FIG. 3is an example diagram of a device300that may correspond to one or more of the devices of environment200. As illustrated, device300may include a bus310, a processing unit320, a main memory330, a read-only memory (ROM)340, a storage device350, an input device360, an output device370, and/or a communication interface380. Bus310may include a path that permits communication among the components of device300.

Processing unit320may include one or more processors, microprocessors, or other types of processing units that may interpret and execute instructions. Main memory330may include one or more random access memories (RAMs) or other types of dynamic storage devices that may store information and/or instructions for execution by processing unit320. ROM340may include one or more ROM devices or other types of static storage devices that may store static information and/or instructions for use by processing unit320. Storage device350may include a magnetic and/or optical recording medium and its corresponding drive.

Input device360may include a mechanism that permits a user to input information to device300, such as a keyboard, a camera, an accelerometer, a gyroscope, a mouse, a pen, a microphone, voice recognition and/or biometric mechanisms, a remote control, a touch screen, a neural interface, etc. Output device370may include a mechanism that outputs information to the user, including a display, a printer, a speaker, etc. Communication interface380may include any transceiver-like mechanism that enables device300to communicate with other devices, networks, and/or systems. For example, communication interface380may include mechanisms for communicating with another device or system via a network.

As described herein, device300may perform certain operations in response to processing unit320executing software instructions contained in a computer-readable medium, such as main memory330. A computer-readable medium may be defined as a non-transitory memory device. A memory device may include space within a single physical memory device or spread across multiple physical memory devices. The software instructions may be read into main memory330from another computer-readable medium, such as storage device350, or from another device via communication interface380. The software instructions contained in main memory330may cause processing unit320to perform processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

AlthoughFIG. 3shows example components of device300, in other implementations, device300may include fewer components, different components, differently arranged components, and/or additional components than depicted inFIG. 3. Alternatively, or additionally, one or more components of device300may perform one or more other tasks described as being performed by one or more other components of device300.

Example Technical Computing Environment

FIG. 4is a diagram of example functional components of TCE240. In one implementation, the functions described in connection withFIG. 4may be performed by one or more components of device300(FIG. 3) and/or by one or more devices300. As shown inFIG. 4, TCE240may include a block diagram editor410, graphical entities420, blocks430, and/or an execution engine440.

Block diagram editor410may include hardware or a combination of hardware and software that may be used to graphically specify models of dynamic systems. In one implementation, block diagram editor410may permit a user to perform actions, such as construct, edit, display, annotate, save, and/or print a graphical model (e.g., a block diagram that visually and/or pictorially represents a dynamic system). In another implementation, block diagram editor410may permit a user to create and/or store data relating to graphical entities420.

A textual interface may be provided to permit interaction with block diagram editor410. A user may write scripts that perform automatic editing operations on a model using the textual interface. For example, the textual interface may provide a set of windows that may act as a canvas for the model, and may permit user interaction with the model. A model may include one or more windows depending on whether the model is partitioned into multiple hierarchical levels.

Graphical entities420may include hardware or a combination of hardware and software that may provide entities (e.g., signal lines, buses, etc.) that represent how data may be communicated between functional and/or non-functional units and blocks430of a model. Blocks430may include fundamental mathematical elements of a block diagram model.

Execution engine440may include hardware or a combination of hardware and software that may process a graphical model to produce simulation results, may convert the graphical model into executable code, and/or may perform other analyses and/or related tasks. In one implementation, for a block diagram graphical model, execution engine440may translate the block diagram into executable entities (e.g., units of execution) following the layout of the block diagram. The executable entities may be compiled and/or executed on a device (e.g., client device210) to implement the functionality specified by the model.

Graphical models may include entities with relationships between the entities, and the relationships and/or the entities may have attributes associated with them. The entities may include model elements such as blocks430and ports. The relationships may include model elements such as lines (e.g., connector lines) and references. The attributes may include model elements such as value information and meta information for the model element associated with the attributes. Graphical models may be associated with configuration information. The configuration information may include information for the graphical model such as model execution information (e.g., numerical integration schemes, fundamental execution period, etc.), model diagnostic information (e.g., whether an algebraic loop should be considered an error or result in a warning), model optimization information (e.g., whether model elements should share memory during execution), model processing information (e.g., whether common functionality should be shared in code that is generated for a model), etc.

Additionally, or alternatively, a graphical model may have executable semantics and/or may be executable. An executable graphical model may be a time based block diagram. A time based block diagram may consist, for example, of blocks (e.g., blocks430) connected by lines (e.g., connector lines). The blocks may consist of elemental dynamic systems such as a differential equation system (e.g., to specify continuous-time behavior), a difference equation system (e.g., to specify discrete-time behavior), an algebraic equation system (e.g., to specify constraints), a state transition system (e.g., to specify finite state machine behavior), an event based system (e.g., to specify discrete event behavior), etc. The lines may represent signals (e.g., to specify input/output relations between blocks or to specify execution dependencies between blocks), variables (e.g., to specify information shared between blocks), physical connections (e.g., to specify electrical wires, pipes with volume flow, rigid mechanical connections, etc.), etc. The attributes may consist of meta information such as sample times, dimensions, complexity (whether there is an imaginary component to a value), data type, etc. associated with the model elements.

In a time based block diagram, ports may be associated with blocks (e.g., blocks430). A relationship between two ports may be created by connecting a line (e.g., a connector line) between the two ports. Lines may also, or alternatively, be connected to other lines, for example by creating branch points. For instance, three or more ports can be connected by connecting a line to each of the ports, and by connecting each of the lines to a common branch point for all of the lines. A common branch point for the lines that represent physical connections may be a dynamic system (e.g., by summing all variables of a certain type to 0 or by equating all variables of a certain type). A port may be an input port, an output port, an enable port, a trigger port, a function-call port, a publish port, a subscribe port, an exception port, an error port, a physics port, an entity flow port, a data flow port, a control flow port, etc.

Relationships between blocks (e.g., blocks430) may be causal and/or non-causal. For example, a model may include a block that represents a continuous-time integration block that may be causally related to a data logging block by using a line (e.g., a connector line) to connect an output port of the continuous-time integration block to an input port of the data logging block. Further, during execution of the model, the value stored by the continuous-time integrator may change as the current time of the execution progresses. The value of the state of the continuous-time integrator may be available on the output port and the connection with the input port of the data logging block may make this value available to the data logging block.

A sample time may be associated with the elements of a graphical model. For example, a graphical model may include a block (e.g., block430) with a continuous sample time such as a continuous-time integration block that may integrate an input value as time of execution progresses. This integration may be specified by a differential equation. During execution the continuous-time behavior may be approximated by a numerical integration scheme that is part of a numerical solver. The numerical solver may take discrete steps to advance the execution time, and these discrete steps may be constant during an execution (e.g., fixed step integration) or may be variable during an execution (e.g., variable-step integration).

Alternatively, or additionally, a graphical model may include a block (e.g., block430) with a discrete sample time such as a unit delay block that may output values of a corresponding input after a specific delay. This delay may be a time interval and this interval may determine a sample time of the block. During execution, the unit delay block may be evaluated each time the execution time has reached a point in time where an output of the unit delay block may change. These points in time may be statically determined based on a scheduling analysis of the graphical model before starting execution.

Alternatively, or additionally, a graphical model may include a block (e.g., block430) with an asynchronous sample time, such as a function-call generator block that may schedule a connected block to be evaluated at a non-periodic time. During execution, a function-call generator block may evaluate an input and when the input attains a specific value when the execution time has reached a point in time, the function-call generator block may schedule a connected block to be evaluated at this point in time and before advancing execution time.

Further, the values of attributes of a graphical model may be inferred from other elements of the graphical model or attributes of the graphical model. For example, the graphical model may include a block (e.g., block430), such as a unit delay block, that may have an attribute that specifies a sample time of the block. When a graphical model has an execution attribute that specifies a fundamental execution period, the sample time of the unit delay block may be inferred from this fundamental execution period.

As another example, the graphical model may include two unit delay blocks (e.g., blocks430) where the output of the first of the two unit delay blocks is connected to the input of the second of the two unit delay block. The sample time of the first unit delay block may be inferred from the sample time of the second unit delay block. This inference may be performed by propagation of model element attributes such that after evaluating the sample time attribute of the second unit delay block, a graph search proceeds by evaluating the sample time attribute of the first unit delay block since it is directly connected to the second unit delay block.

The values of attributes of a graphical model may be set to characteristics settings, such as one or more inherited settings, one or more default settings, etc. For example, the data type of a variable that is associated with a block (e.g., block430) may be set to a default such as a double. Because of the default setting, an alternate data type (e.g., a single, an integer, a fixed point, etc.) may be inferred based on attributes of elements that the graphical model comprises (e.g., the data type of a variable associated with a connected block) and/or attributes of the graphical model. As another example, the sample time of a block may be set to be inherited. In case of an inherited sample time, a specific sample time may be inferred based on attributes of elements that the graphical model comprises and/or attributes of the graphical model (e.g., a fundamental execution period).

AlthoughFIG. 4shows example functional components of TCE240, in other implementations, TCE240may include fewer functional components, different functional components, differently arranged functional components, and/or additional functional components than depicted inFIG. 4. Alternatively, or additionally, one or more functional components of TCE240may perform one or more other tasks described as being performed by one or more other functional components of TCE240.

Example Technical Computing Environment Operations

FIG. 5is a diagram of example operations500capable of being performed by TCE240. TCE240may include the features described above in connection with, for example, one or more ofFIGS. 1-4. As illustrated inFIG. 5, TCE240may include a testing component510. The functions described in connection with testing component510may be performed by one or more components of device300(FIG. 3) and/or by one or more devices300.

As further shown inFIG. 5, testing component510may receive code520generated by TCE240. TCE code520may include text-based code that may require further processing to execute, binary code that may be executed, text files that may be executed in conjunction with other executables, etc. In one example, TCE code520may include one or more calculated values (e.g., actual_value) that may be tested by testing component510.

Testing component510may receive a value modifier530, a test case540, and a constraint550via an input instruction (e.g., produced programmatically or received from a person testing (e.g., a tester) TCE code520). Value modifier530may include a mechanism that wraps the tested value (e.g., actual_value) and presents the tested value to constraint550in a different manner. For example, value modifier530(e.g., AnyElementOf) may enable the determination of whether any element of the tested value satisfies constraint550. Alternatively, or additionally, value modifier530may include syntax that enables data structures, such as simple arrays, cell arrays, structure arrays, objects, etc. to be presented to constraint550. Value modifiers530may provide an additional degree of freedom for tests and may include intuitive and literate APIs for presentation of tested values to multiple constraints550.

Test case540may include syntax (e.g., verifyThat) to determine whether the tested value satisfies constraint550. Constraint550may include a formal and literate description of what characteristics the tested value should possess. For example, constraint550(e.g., IsEqualTo(5)) may be applied to the tested value to determine whether the tested value is equal to five. Alternatively, or additionally, constraint550may include other syntax, such as IsGreaterThan, IsLessThan, ContainsSubstring, IsOfClass, etc.

Testing component510may generate a test for TCE code520based on value modifier530, test case540, and constraint550. In one example implementation, testing component510may combine value modifier530, test case540, and constraint550to create a test API, and may generate the test based on the test API. Testing component510may perform the test on TCE code520to generate a result560. In one example, result560may include diagnostic information570(e.g., “At least one element of actual_value satisfies the IsEqualTo constraint.”). Testing component510may output (e.g., display to the tester) and/or may store result560.

In one example implementation, value modifier530may enable testing component510to create a test API that reads like a sentence so that the test may be self documenting and easy to read. Value modifier530may operate on the actual values (e.g., of TCE code520), and may present the actual values to constraint550in a manner that allows a greater degree of flexibility in how the actual values are compared against constraints550. Value modifier530may include a base class that can be sub-classed and supported by constraints550. For example, value modifier530may include syntax (e.g., EveryElementOf) to compare every element of a value (e.g., “a”) to a constraint (e.g., IsGreaterThan(4)) to determine whether every element of the value is greater than four. The test API for such a value modifier530may include the syntax verifyThat(EveryElementOf(a), IsGreaterThan(4)).

Alternatively, or additionally, value modifier530may utilize syntax (e.g., AnyCellOf), for any cell of a value (e.g., “a”) and a constraint (e.g., IsEqualTo(‘Some String’)), to assert that any cell of the value is equal to a particular string. The test API for such a value modifier530may include the syntax assertThat(AnyCellOf(a), IsEqualTo(‘Some String’)). Alternatively, or additionally, value modifier530may utilize syntax (e.g., EveryMethodOf), for every method of a value (e.g., “cls”) and a constraint (e.g., IsPublic), to assume that every method of the value is a public method. The test API for such a value modifier530may include the syntax assume That(EveryMethodOf(cls), IsPublic). Alternatively, or additionally, value modifier530may utilize syntax (e.g., TextInside), for text inside of a file (e.g., “file”) and a constraint (e.g., ContainsSubstring(‘foo’)), to verify that text inside the file contains the substring “foo.” The test API for such a value modifier530may include the syntax verifyThat(TextInside(file), ContainsSubstring(‘foo’)).

AlthoughFIG. 5shows example operations capable of being performed by TCE240, in other implementations, TCE240may perform fewer operations, different operations, and/or additional operations than depicted inFIG. 5. Alternatively, or additionally, one or more components ofFIG. 5may perform one or more other tasks described as being performed by one or more other components ofFIG. 5.

Example Testing Component Operations

FIG. 6is a diagram of example functional components of testing component510(FIG. 5). The functions described in connection with testing component510may be performed by one or more components of device300(FIG. 3) and/or by one or more devices300. As shown inFIG. 6, testing component510may include an API creator component600and a code tester component610.

API creator component600may receive value modifier530, test case540, and constraint550, and may create a test API620based on value modifier530, test case540, and constraint550. For example, value modifier530may include particular syntax (e.g., AnyElementOf), test case540may include particular syntax (e.g., verifyThat), and constraint550may include particular syntax (e.g., IsEqualTo). If TCE code520includes a value (e.g., actual_value), API creator component600may create test API620to include the syntax: verifyThat(AnyElementOf(actual_value), IsEqualTo(5)). Such a test API620may used to verify that any element of the value (e.g., actual_value) is equal to five. As further shown inFIG. 6, API creator component600may provide test APIs620to code tester component610.

Code tester component610may receive test API620and may generate a test based on test API620. For example, code tester component610may combine test API620with one or more other test APIs620to create the test. As further shown inFIG. 6, code tester component610may receive TCE code520, and may perform the test on TCE code520to generate result560. Returning to the example above, code tester component610may verify that any element of the value (e.g., actual_value) is equal to five, and may output result560as either “true” (e.g., if one element of the value equals five) or “false” (e.g., if no elements of the value equal five). Code tester component610may output (e.g., display) and/or store result560.

AlthoughFIG. 6shows example functional components of testing component510, in other implementations, testing component510may include fewer functional components, different functional components, differently arranged functional components, and/or additional functional components than depicted inFIG. 6. Alternatively, or additionally, one or more functional components of testing component510may perform one or more other tasks described as being performed by one or more other functional components of testing component510.

FIG. 7is a diagram of example operations700capable of being performed by testing component510. Testing component510may include the features described above in connection with, for example, one or more ofFIGS. 1, 5, and 6. As illustrated inFIG. 7, testing component510may receive code710generated by TCE240. In one example, TCE code710may include a value (e.g., actual_value) that needs to be verified by testing component510.

Prior to receiving TCE code710, testing component510may receive value modifier530(e.g., AnyElementOf), test case540(e.g., verifyThat), and/or constraint550(e.g., IsEqualTo(5)) from a tester of TCE code710. Testing component510may generate a test720for TCE code710based on value modifier530, test case540, and/or constraint550. In one example, testing component510may combine value modifier530, test case540, and constraint550to create one or more test APIs, and may generate test720based on the test API(s). In one example, test720may include the following syntax:verifyThat(AnyElementOf(actual_value), IsEqualTo(5)).

Testing component510may perform test720on TCE code710to generate a result. For example, as shown inFIG. 7, when any element of the actual_value equals five, the IsEqualTo constraint may be satisfied, as indicated by reference number730, and an equal diagnostic740may be output by testing component510. In one example, equal diagnostic740may include the following information:At least one element of actual_value satisfies the IsEqualTo constraint.

Alternatively, or additionally, as shown inFIG. 7, when no elements of the actual_value equal five, the IsEqualTo constraint may not be satisfied, as indicated by reference number750, and a not equal diagnostic760may be output by testing component510. In one example, not equal diagnostic760may include the following information:No elements of actual_value satisfy the IsEqualTo constraint.

AlthoughFIG. 7shows example operations capable of being performed by testing component510, in other implementations, testing component510may perform fewer operations, different operations, and/or additional operations than depicted inFIG. 7. Alternatively, or additionally, one or more components ofFIG. 7may perform one or more other tasks described as being performed by one or more other components ofFIG. 7.

FIG. 8is a diagram of further example operations800capable of being performed by testing component510. Testing component510may include the features described above in connection with, for example, one or more ofFIGS. 1 and 5-7. As shown inFIG. 8, testing component510may receive code810generated by TCE240. In one example, TCE code810may include an array (e.g., array) that needs to be verified by testing component510.

Prior to receiving TCE code810, testing component510may receive value modifier530(e.g., EveryElementOf), test case540(e.g., verifyThat), and/or constraint550(e.g., IsGreaterThan(4)) from a tester of TCE code810. Testing component510may generate a test820for TCE code810based on value modifier530, test case540, and/or constraint550. In one example, testing component510may combine value modifier530, test case540, and/or constraint550to create one or more test APIs, and may generate test820based on the test API(s). In one example, test820may include the following syntax:verifyThat(EveryElementOf(array), IsGreaterThan(4)).

Testing component510may perform test820on TCE code810to generate a result. For example, as shown inFIG. 8, when every element of the array is greater than four, the IsGreaterThan constraint may be satisfied, as indicated by reference number830, and a greater than diagnostic840may be output by testing component510. In one example, greater than diagnostic840may include the following information:Every element of array satisfies the IsGreaterThan constraint.

Alternatively, or additionally, as shown inFIG. 8, when at least one element of the array is not greater than four, the IsGreaterThan constraint may not be satisfied, as indicated by reference number850, and a not greater diagnostic860may be output by testing component510. In one example, not greater than diagnostic860may include the following information:At least one element of array does not satisfy the IsGreaterThan constraint.

AlthoughFIG. 8shows example operations capable of being performed by testing component510, in other implementations, testing component510may perform fewer operations, different operations, and/or additional operations than depicted inFIG. 8. Alternatively, or additionally, one or more components ofFIG. 8may perform one or more other tasks described as being performed by one or more other components ofFIG. 8.

Example Process

FIGS. 9 and 10are flow charts of an example process900for providing modifiers that customize presentation of tested values to constraints. In one implementation, process900may be performed by client device210/TCE240. Alternatively, or additionally, process900may be performed by another device or a group of devices separate from or including client device210/TCE240, such as server device220.

As shown inFIG. 9, process900may include receiving code generated via a technical computing environment (TCE) (block910), and receiving a value modifier, a test case, and a constraint (block920). For example, in an implementation described above in connection withFIG. 5, testing component510may receive code520generated by TCE240. TCE code520may include text-based code that may require further processing to execute, binary code that may be executed, text files that may be executed in conjunction with other executables, etc. Testing component510may receive a value modifier530, a test case540, and a constraint550from a person testing (e.g., a tester) TCE code520. Value modifier530may include a mechanism that wraps the tested value (e.g., actual value) and presents the tested value to constraint550in a different manner. Test case540may include a test (e.g., verifyThat) to determine whether the tested value satisfies constraint550. Constraint550may include a formal and literate description of what characteristics the tested value should possess.

As further shown inFIG. 9, process900may include generating a test based on the value modifier, the test case, and the constraint (block930), performing the test on the code to generate a result (block940), and outputting and/or storing the result (block950). For example, in an implementation described above in connection withFIG. 5, testing component510may generate a test for TCE code520based on value modifier530, test case540, and/or constraint550. Testing component510may perform the test on TCE code520to generate result560. In one example, result560may include diagnostic information570(e.g., “At least one element of actual_value satisfies the IsEqualTo constraint.”). Testing component510may output (e.g., display to the tester) and/or may store result560.

Process block930may include the process blocks depicted inFIG. 10. As shown inFIG. 10, process block930may include combining the value modifier, the test case, and the constraint to create a test API (block1000), and generating the test based on the test API (block1010). For example, in an implementation described above in connection withFIG. 5, testing component510may combine value modifier530, test case540, and constraint550to create a test API, and may generate the test based on the test API.

CONCLUSION

Systems and/or methods described herein may provide modifiers that customize a manner in which a tested value of code is presented to a test constraint for verification. For example, a constraint (e.g., IsEqualTo(5)) may be applied to a tested value (e.g., actual_value), via syntax. The systems and/or methods may provide a modifier that wraps the tested value and presents the tested value to the constraint in a different manner. For example, if the IsEqualTo(5) constraint is used and the actual_value is an array of elements, the constraint may be satisfied when only one of the elements of the array is equal to five. The systems and/or methods may provide a modifier (e.g., AnyElementOf) that enables the determination of whether any element of the actual value array satisfies the IsEqualTo(5) constraint, according to the following syntax: verifyThat(AnyElementOf(actual_value), IsEqualTo(5)).

For example, while series of blocks have been described with regard toFIGS. 9 and 10, the blocks and/or the order of the blocks may be modified in other implementations. Further, non-dependent blocks may be performed in parallel.

Further, certain portions of the implementations may be implemented as a “component” that performs one or more functions. This component may include hardware, such as a processor, an application-specific integrated circuit (ASIC), or a field-programmable gate array (FPGA), or a combination of hardware and software.