Documentation ¶
Index ¶
- type ActionDto
- type AdditionalInfoDto
- type AllTargetsDto
- type AuthenticationDto
- type ContentType
- type ControllerInfoDto
- type CookieLoginDto
- type CoverageDto
- type ExtraHeuristicsDto
- type FullObjectiveCoverageDto
- type HeaderDto
- type HeuristicEntryDto
- type HttpVerb
- type JsonTokenPostLoginDto
- type Objective
- type OutputFormat
- type StringSpecializationInfoDto
- type SutInfoDto
- type SutRunDto
- type TargetInfoDto
- type TestResultsDto
- type Type
- type UnitsInfoDto
- type WrappedResponseDto
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type ActionDto ¶
type ActionDto struct { // The index of this action in the test. // Eg, in a test with 10 indices, the index would be // between 0 and 9 Index int `json:"index"` // A list (possibly empty) of String values used in the action. // This info can be used for different kinds of taint analysis, eg // to check how such values are used in the SUT InputVariables []string `json:"inputVariables"` }
type AdditionalInfoDto ¶
type AdditionalInfoDto struct { // QueryParameters In REST APIs, it can happen that some query parameters do not appear in the schema if they are // indirectly accessed via objects like WebRequest. // But we can track at runtime when such kind of objects are used to access the query parameters QueryParameters []string `json:"queryParameters"` // Headers In REST APIs, it can happen that some HTTP headers do not appear in the schema if they are indirectly // accessed via objects like WebRequest. // But we can track at runtime when such kind of objects are used to access the query parameters Headers []string `json:"headers"` // LastExecutedStatement Keep track of the last executed statement done in the SUT. // But not in the third-party libraries, just the business logic of the SUT. // The statement is represented with a descriptive unique id, like the class name and line number. LastExecutedStatement string `json:"lastExecutedStatement"` }
type AllTargetsDto ¶
type AllTargetsDto struct { Files []string `json:"files"` Lines []string `json:"lines"` Branches []string `json:"branches"` Statements []string `json:"statements"` }
AllTargetsDto returns a list of all the targets
type AuthenticationDto ¶
type AuthenticationDto struct { // Name given name to this authentication info. // Just needed for display/debugging reasons Name string `json:"name"` // Headers The headers needed for authentication Headers []HeaderDto `json:"headers"` // CookieLogin If the login is based on cookies, need to provide info on how to get such a cookie CookieLogin CookieLoginDto `json:"cookieLogin"` JsonTokenPostLogin JsonTokenPostLoginDto `json:"jsonTokenPostLogin"` }
AuthenticationDto To authenticate a user, would need specific settings, like specific values in the HTTP headers (eg, cookies)
type ContentType ¶
type ContentType int
const ( ContentTypeJSON ContentType = iota ContentTypeXWWWFormUrlEncoded )
func (ContentType) String ¶
func (e ContentType) String() string
type ControllerInfoDto ¶
type ControllerInfoDto struct { // FullName The full qualifying name of the controller. // This will be needed when tests are generated, as those // will instantiate and start the controller directly FullName string `json:"fullName"` // IsInstrumentationOn Whether the system under test is running with instrumentation // to collect data about its execution IsInstrumentationOn bool `json:"isInstrumentationOn"` }
type CookieLoginDto ¶
type CookieLoginDto struct { // Username The id of the user Username string `json:"username"` // Password The password of the user. This must NOT be hashed. Password string `json:"password"` // UsernameField The name of the field in the body payload containing the username UsernameField string `json:"usernameField"` // PasswordField The name of the field in the body payload containing the password PasswordField string `json:"passwordField"` // LoginEndpointUrl The URL of the endpoint, e.g., "/login" LoginEndpointUrl string `json:"loginEndpointUrl"` // HttpVerb The HTTP verb used to send the data. Usually a "POST". HttpVerb string `json:"httpVerb"` // ContentType The encoding type used to specify how the data is sent ContentType string `json:"contentType"` }
CookieLoginDto Information on how to do a login based on username/password, from which we then get a cookie back
type CoverageDto ¶
type ExtraHeuristicsDto ¶
type ExtraHeuristicsDto struct { // List of extra heuristic values we want to optimize Heuristics []HeuristicEntryDto `json:"heuristics"` }
ExtraHeuristicsDto Represents possible extra heuristics related to the code execution and that do apply to all the reached testing targets. Example: rewarding SQL "select" operations that return non-empty sets
type FullObjectiveCoverageDto ¶
type FullObjectiveCoverageDto struct { Files []CoverageDto `json:"files"` Lines []CoverageDto `json:"lines"` Branches []CoverageDto `json:"branches"` Statements []CoverageDto `json:"statements"` }
type HeaderDto ¶
type HeaderDto struct { // Name The header name Name string `json:"name"` // Value The value of the header Value string `json:"value"` }
HeaderDto A HTTP header, which is a key=value pair
type HeuristicEntryDto ¶
type JsonTokenPostLoginDto ¶
type JsonTokenPostLoginDto struct { // UserId The id representing this user that is going to logi UserId string `json:"userId"` // Endpoint The endpoint where to execute the login Endpoint string `json:"endpoint"` // JsonPayload The payload to send, as stringified JSON object JsonPayload string `json:"jsonPayload"` // ExtractTokenField How to extract the token from a JSON response, as such JSON could have few fields, possibly nested. // It is expressed as a JSON Pointe ExtractTokenField string `json:"extractTokenField"` // HeaderPrefix When sending out the obtained token in the Authorization header, // specify if there should be any prefix (e.g., "Bearer " or "JWT " HeaderPrefix string `json:"headerPrefix"` }
type Objective ¶
type Objective int
Objective Should we try to minimize or maximize the heuristic?
const ( // MINIMIZE_TO_ZERO The lower, the better. // Minimum is 0. It can be considered as a "distance" to minimize. MINIMIZE_TO_ZERO Objective = iota // MAXIMIZE The higher, the better. // Note: given x, we could rather consider the value 1/x to minimize. But that wouldn't work for negative x, // and also would make debugging more difficult (ie better to look at the raw, non-transformed values). MAXIMIZE )
type OutputFormat ¶
type OutputFormat int
OutputFormat Note: this enum must be kept in sync with what declared in org.evomaster.core.output.OutputFormat
const ( JavaJunit5 OutputFormat = iota JavaJunit4 KotlinJunit4 KotlinJunit5 JsJest CsharpXunit Go )
func (OutputFormat) String ¶
func (e OutputFormat) String() string
type SutInfoDto ¶
type SutInfoDto struct { // RestProblem If the SUT is a RESTful API, here there will be the info // on how to interact with it RestProblem problem.RestProblemDto `json:"restProblem"` // IsSutRunning Whether the SUT is running or not IsSutRunning bool `json:"isSutRunning"` // DefaultOutputFormat When generating test cases for this SUT, specify the default // preferred output format (eg JUnit 4 in Java) DefaultOutputFormat string `json:"defaultOutputFormat"` // BaseUrlOfSUT The base URL of the running SUT (if any). // E.g., "http://localhost:8080" // It should only contain the protocol and the hostname/port BaseUrlOfSUT string `json:"baseUrlOfSUT,omitempty"` // InfoForAuthentication There is no way a testing system can guess passwords, even // if given full access to the database storing them (ie, reversing // hash values). As such, the SUT might need to provide a set of valid credentials InfoForAuthentication []AuthenticationDto `json:"infoForAuthentication"` // UnitsInfoDto Information about the "units" in the SUT. UnitsInfoDto UnitsInfoDto `json:"unitsInfoDto"` }
type SutRunDto ¶
type SutRunDto struct { // Run Whether the SUT should be running Run bool `json:"run"` // ResetState Whether the internal state of the SUT should be reset ResetState bool `json:"resetState"` // CalculateSqlHeuristics Whether SQL heuristics should be computed. // Note: those can be very expensive CalculateSqlHeuristics bool `json:"calculateSqlHeuristics"` // ExtractSqlExecutionInfo Whether SQL execution info should be saved. ExtractSqlExecutionInfo bool `json:"extractSqlExecutionInfo"` }
type TargetInfoDto ¶
type TargetInfoDto struct { // The id of the target Id int `json:"id"` // A unique id for the target that is also descriptive for it. // Note: this string will usually be much longer than the numeric id. // This field is optional: usually sent only the first time the target // has been encountered, and will be mainly used for debugging reasons DescriptiveId string `json:"descriptiveId"` // The fitness value for this target, in [0,1], where 1 means covered Value float64 `json:"value"` // An id identify the action that led to this fitness score for this // testing target. // For example, it can be the index in the list representation of // the test case. // Can be negative if target was never reached. // But this means that {@code value} must be 0 ActionIndex int `json:"actionIndex"` }
type TestResultsDto ¶
type TestResultsDto struct { Targets []TargetInfoDto `json:"targets"` AdditionalInfoList []AdditionalInfoDto `json:"additionalInfoList"` ExtraHeuristics []ExtraHeuristicsDto `json:"extraHeuristics"` }
type Type ¶
type Type int
Type The type of extra heuristic. Note: for the moment, we only have heuristics on SQL commands
type UnitsInfoDto ¶
type UnitsInfoDto struct { // UnitNames Then name of all the units (eg classes) in the SUT UnitNames []string `json:"unitNames"` // NumberOfLines The total number of lines/statements/instructions in all units of the whole SUT NumberOfLines int `json:"numberOfLines"` // NumberOfBranches The total number of branches in all units of the whole SUT NumberOfBranches int `json:"numberOfBranches"` // Number of replaced method testability transformations. But only for SUT units. NumberOfReplacedMethodsInSut int `json:"numberOfReplacedMethodsInSut,omitempty"` // Number of replaced method testability transformations. // But only for third-party library units (ie all units not in the SUT). NumberOfReplacedMethodsInThirdParty int `json:"numberOfReplacedMethodsInThirdParty,omitempty"` // Number of tracked methods. Those are special methods for which // we explicitly keep track of how they are called (eg their inputs). NumberOfTrackedMethods int `json:"numberOfTrackedMethods,omitempty"` }
UnitsInfoDto Information about the "units" in the SUT. In case of OO languages like Java and Kotlin, those will be "classes"
type WrappedResponseDto ¶
type WrappedResponseDto[T any] struct { // Data The actual payload we are sending and are "wrapping" here Data T `json:"data,omitempty"` // Error If this is not null, then "data" must be null. Error string `json:"error,omitempty"` }
WrappedResponseDto In REST, when we have an error, at most we would see an HTTP status code. But it can be very useful to get an actual description of the error. So, it is a common practice to have "Wrapped Responses", which can contain the error message (if any)
func NewWrappedResponseDtoWithData ¶
func NewWrappedResponseDtoWithData[T any](data T) WrappedResponseDto[T]
func NewWrappedResponseDtoWithError ¶
func NewWrappedResponseDtoWithError(msg string) WrappedResponseDto[interface{}]
func NewWrappedResponseDtoWithNoData ¶
func NewWrappedResponseDtoWithNoData() WrappedResponseDto[interface{}]
Source Files ¶
- action_dto.go
- additional_info_dto.go
- all_targets_dto.go
- authentication_dto.go
- controller_info_dto.go
- cookie_login_dto.go
- extra_heuristics_dto.go
- header_dto.go
- heuristic_entry_dto.go
- json_token_post_login_dto.go
- string_specialization_info_dto.go
- sut_info_dto.go
- sut_run_dto.go
- target_info_dto.go
- test_results_dto.go
- units_info_dto.go
- wrapped_response_dto.go