Mocking

Package gae provides a fakable wrapped interface for the appengine SDK's APIs. This means that it's possible to mock all of the supported appengine APIs for testing (or potentially implement a different backend for them). gae currently provides interfaces for: Additional features include: The gae library is organized into several subpackages: A service defintion lives under the `service` subfolder, and defines the user-facing interface for a service. Each service has a few common types and functions. Common types are: And common functions are: The impl subdirectory contains a couple different service implementations, depending on your needs. 'prod' is the production (e.g. real appengine-backed) implementation. It calls through to the original appengine SDK. 'memory' is a truly parallel in-memory testing implementation. It should be functionally the same as the production appengine services, implementing many of the real-world quirks of the actual services. It also implements the services' Testable interface, for those services which define those interfaces. 'dummy' provides a bunch of implementations of the various RawInterfaces. These implementations just panic with an appropriate message, depending on which API method was called. They're useful to embed in filter or service implementations as stubs while you're implementing the filter. Each service also supports "filters". Filters are proxy objects which have the same interface as the service they're filtering, and pass data through to the previous filter in the stack. Conceptually, a filtered version of, for example, the Datastore, could look like: Filters may or may not have state, it's up to the filter itself. In the case of the count filter, it returns its state from the Filter<Service> method, and the state can be observed to see how many times each API was invoked. Since filters stack, we can compare counts from rawCount versus userCount to see how many calls to the actual real datastore went through, vs. how many went to memcache, for example. Note that Filters apply only to the service.RawInterface. All implementations of service.Interface boil down to calls to service.RawInterface methods, but it's possible that bad calls to the service.Interface methods could return an error before ever reaching the filters or service implementation.

Package goebpf provides simple and convenient interface to Linux eBPF system. Extended Berkeley Packet Filter (eBPF) is a highly flexible and efficient virtual machine in the Linux kernel allowing to execute bytecode at various hook points in a safe manner. It is actually close to kernel modules which can provide the same functionality, but without cost of kernel panic if something went wrong. The library is intended to simplify work with eBPF programs. It takes care of low level routine implementation to make it easy to load/run/manage eBPF programs. Currently supported functionality: - Read / parse clang/llmv compiled binaries for eBPF programs / maps - Creates / loads eBPF program / eBPF maps into kernel - Provides simple interface to interact with eBPF maps - Has mock versions of eBPF objects (program, map, etc) in order to make writing unittests simple. eXpress Data Path - provides a bare metal, high performance, programmable packet processing at the closest at possible point to network driver. That makes it ideal for speed without compromising programmability. Key benefits includes following: - It does not require any specialized hardware (program works in kernel’s "VM") - It does not require kernel bypass - It does not replace the TCP/IP stack Considering very simple and highly effective way to DROP all packets from given source IPv4 address: XDP program (written in C): Once compiled can be used by goebpf in the following way: Perf Events (originally Performance Counters for Linux) is powerful kernel instrument for tracing, profiling and a lot of other cases like general events to user space. Usually it is implemented using special eBPF map type "BPF_MAP_TYPE_PERF_EVENT_ARRAY" as a container to send events into. A simple example could be to log all TCP SYN packets into user space from XDP program: There are currently two types of supported probes: kprobes, and kretprobes (also called return probes). A kprobe can be inserted on virtually any instruction in the kernel. A return probe fires when a specified function returns. For example, you can trigger eBPF code to run when a kernel function starts by attaching the program to a “kprobe” event. Because it runs in the kernel, eBPF code is extremely high performance. A simple example could be to log all process execution events into user space from Kprobe program:

Package pgmock provides the ability to mock a PostgreSQL server.

Package redigomock is a mock for redigo library (redis client) Redigomock basically register the commands with the expected results in a internal global variable. When the command is executed via Conn interface, the mock will look to this global variable to retrieve the corresponding result. To start a mocked connection just do the following: Now you can inject it whenever your system needs a redigo.Conn because it satisfies all interface requirements. Before running your tests you need beyond of mocking the connection, registering the expected results. For that you can generate commands with the expected results. As the Expect method from Command receives anything (interface{}), another method was created to easy map the result to your structure. For that use ExpectMap: You should also test the error cases, and you can do it in the same way of a normal result. Sometimes you will want to register a command regardless the arguments, and you can do it with the method GenericCommand (mainly with the HMSET). All commands are registered in a global variable, so they will be there until all your test cases ends. So for good practice in test writing you should in the beginning of each test case clear the mock states. Let's see a full test example. Imagine a Person structure and a function that pick up this person in Redis using redigo library (file person.go): Now we need to test it, so let's create the corresponding test with redigomock (fileperson_test.go): When you use redis as a persistent list, then you might want to call the same redis command multiple times. For example: To test it, you can chain redis responses. Let's write a test case: In the first iteration of the loop redigomock would return "www.some.url.com", then "www.another.url.com" and finally redis.ErrNil. Sometimes providing expected arguments to redigomock at compile time could be too constraining. Let's imagine you use redis hash sets to store some data, along with the timestamp of the last data update. Let's expand our Person struct: And add a function updating personal data (phone number for example). Please notice that the update timestamp can't be determined at compile time: Unit test: As you can see at the position of current timestamp redigomock is told to match AnyInt struct created by NewAnyInt() method. AnyInt struct will match any integer passed to redigomock from the tested method. Please see fuzzyMatch.go file for more details. The interface of Conn which matches redigo.Conn is safe for concurrent use, but the mock-only methods and fields, like Command and Errors, should not be accessed concurrently with such calls.

Package mocks is a generated GoMock package.

package pgxmock is a mock library implementing pgx connector. Which has one and only purpose - to simulate pgx driver behavior in tests, without needing a real database connection. It helps to maintain correct **TDD** workflow. It does not require (almost) any modifications to your source code in order to test and mock database operations. Supports concurrency and multiple database mocking. The driver allows to mock any pgx driver method behavior.

package pgxmock is a mock library implementing pgx connector. Which has one and only purpose - to simulate pgx driver behavior in tests, without needing a real database connection. It helps to maintain correct **TDD** workflow. It does not require (almost) any modifications to your source code in order to test and mock database operations. Supports concurrency and multiple database mocking. The driver allows to mock any pgx driver method behavior.

Package sqlmock is a mock library implementing sql driver. Which has one and only purpose - to simulate any sql driver behavior in tests, without needing a real database connection. It helps to maintain correct **TDD** workflow. It does not require any modifications to your source code in order to test and mock database operations. Supports concurrency and multiple database mocking. The driver allows to mock any sql driver method behavior.

Package mocks is a generated GoMock package.

Package govpp provides the entry point to govpp functionality. It provides the API for connecting the govpp core to VPP either using the default VPP adapter, or using the adapter previously set by SetAdapter function (useful mostly just for unit/integration tests with mocked VPP adapter). To create a connection to VPP, use govpp.Connect function: Make sure you close the connection after using it. If the connection is not closed, it will leak resources. Please note that only one VPP connection is allowed for a single process. In case you need to mock the connection to VPP (e.g. for testing), use the govpp.SetAdapter function before calling govpp.Connect. Once connected to VPP, use the functions from the api package to communicate with it.

Package govcr records and replays HTTP interactions for offline unit / behavioural / integration tests thereby acting as an HTTP mock. This project was inspired by php-vcr which is a PHP port of VCR for ruby. For usage and more information, please refer to the project's README at: https://github.com/seborama/govcr Example_simpleVCR is an example use of govcr. It shows how to use govcr in the simplest case when the default http.Client suffices. Example2 is an example use of govcr. It shows the use of a VCR with a custom Client. Here, the app executes a GET request. Example_simpleVCR is an example use of govcr. It shows how to use govcr in the simplest case when the default http.Client suffices. Example_simpleVCR is an example use of govcr. It shows a simple use of a Long Play cassette (i.e. compressed). Example_simpleVCR is an example use of govcr. It shows how to use govcr in the simplest case when the default http.Client suffices. Example_number7BodyInjection will show how bodies can be rewritten. We will take a varying ID from the request URL, neutralize it and also change the ID in the body of the response.

Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package. Package mocks is a generated GoMock package.

Package micro is a pluggable framework for microservices

Package micro is a pluggable framework for microservices

Package micro is a pluggable framework for microservices

Package micro is a pluggable framework for microservices

Package govcr records and replays HTTP interactions for offline unit / behavioural / integration tests thereby acting as an HTTP mock. This project was inspired by php-vcr which is a PHP port of VCR for ruby. For usage and more information, please refer to the project's README at: https://github.com/seborama/govcr Example_simpleVCR is an example use of govcr. It shows how to use govcr in the simplest case when the default http.Client suffices. Example2 is an example use of govcr. It shows the use of a VCR with a custom Client. Here, the app executes a GET request. Example_simpleVCR is an example use of govcr. It shows how to use govcr in the simplest case when the default http.Client suffices.

Package micro is a pluggable framework for microservices

Package testing define helper / mock for unit testing Because golang likes return error object instead of exception/panic, always handle error return values is a good practise. But sometimes it is impossible to got error, such as read from memory buffer, not handler them maybe maybe loose error because someday code changes, but handle them needs a lot of duplicate codes. In package testing contains many test helper packages, suffix with `th', to handle these never happen errors. Test helper check the error result, if it is not nil, using testing.Fatal(err) to log the error object and abort current test case execution.

Package micro is a pluggable framework for microservices

Package micro is a pluggable framework for microservices

Package micro is a pluggable framework for microservices

Package micro is a pluggable framework for microservices

Package micro is a pluggable framework for microservices

Package micro is a pluggable framework for microservices

Package bark provides an abstraction for loggers and stats reporters used in Uber's Go libraries. It decouples these libraries slightly from specific logger implementations; for example, the popular open source library logrus, which offers no interfaces (and thus cannot be, for instance, easily mocked). Users may choose to implement the interfaces themselves or to use the provided wrappers for logrus loggers and cactus/go-statsd-client stats reporters.

package pgxmock is a mock library implementing pgx connector. Which has one and only purpose - to simulate pgx driver behavior in tests, without needing a real database connection. It helps to maintain correct **TDD** workflow. It does not require (almost) any modifications to your source code in order to test and mock database operations. Supports concurrency and multiple database mocking. The driver allows to mock any pgx driver method behavior.

Package mock provides a mocking framework for Go. https://github.com/maraino/go-mock

Package oglematchers provides a set of matchers useful in a testing or mocking framework. These matchers are inspired by and mostly compatible with Google Test for C++ and Google JS Test. This package is used by github.com/jacobsa/ogletest and github.com/jacobsa/oglemock, which may be more directly useful if you're not writing your own testing package or defining your own matchers.

Package retry implements flexible retry loops, including support for channel cancellation, mocked time, and composable retry strategies including exponential backoff with jitter. The basic usage is as follows: See examples for details of suggested usage.

test contains the stubs required for counterfeiter to generate the mocks used for tests The mocks are created by running `go generate ./...` as described in the counterfeiter readme

Package gsrv creates a test gRPC server that is useful when mocking a gRPC service. A complete example of mocking a gRPC service that leverges this package is available at https://github.com/weathersource/go-gsrv/tree/master/examples/foo This package is based on Google's testutil.Server. Original code is found at https://github.com/GoogleCloudPlatform/google-cloud-go/blob/master/internal/testutil/server.go

Package ovirtclient provides a human-friendly Go client for the oVirt Engine. It provides an abstraction layer for the oVirt API, as well as a mocking facility for testing purposes. This documentation contains two parts. This introduction explains setting up the client with the credentials. The API doc contains the individual API calls. When reading the API doc, start with the Client interface: it contains all components of the API. The individual API's, their documentation and examples are located in subinterfaces, such as DiskClient. There are several ways to create a client instance. The most basic way is to use the New() function as follows: The mock client simulates the oVirt engine behavior in-memory without needing an actual running engine. This is a good way to provide a testing facility. It can be created using the NewMock method: That's it! However, to make it really useful, you will need the test helper which can set up test fixtures. The test helper can work in two ways: Either it sets up test fixtures in the mock client, or it sets up a live connection and identifies a usable storage domain, cluster, etc. for testing purposes. The ovirtclient.NewMockTestHelper() function can be used to create a test helper with a mock client in the backend: The easiest way to set up the test helper for a live connection is by using environment variables. To do that, you can use the ovirtclient.NewLiveTestHelperFromEnv() function: This function will inspect environment variables to determine if a connection to a live oVirt engine can be established. The following environment variables are supported: URL of the oVirt engine API. Mandatory. The username for the oVirt engine. Mandatory. The password for the oVirt engine. Mandatory. A file containing the CA certificate in PEM format. Provide the CA certificate in PEM format directly. Disable certificate verification if set. Not recommended. The cluster to use for testing. Will be automatically chosen if not provided. ID of the blank template. Will be automatically chosen if not provided. Storage domain to use for testing. Will be automatically chosen if not provided. VNIC profile to use for testing. Will be automatically chosen if not provided. You can also create the test helper manually: This library provides extensive logging. Each API interaction is logged on the debug level, and other messages are added on other levels. In order to provide logging this library uses the go-ovirt-client-log (https://github.com/oVirt/go-ovirt-client-log) interface definition. As long as your logger implements this interface, you will be able to receive log messages. The logging library also provides a few built-in loggers. For example, you can log via the default Go log interface: Or, you can also log in tests: You can also disable logging: Finally, we also provide an adapter library for klog here: https://github.com/oVirt/go-ovirt-client-log-klog Modern-day oVirt engines run secured with TLS. This means that the client needs a way to verify the certificate the server is presenting. This is controlled by the tls parameter of the New() function. You can implement your own source by implementing the TLSProvider interface, but the package also includes a ready-to-use provider. Create the provider using the TLS() function: This provider has several functions. The easiest to set up is using the system trust root for certificates. However, this won't work own Windows: Now you need to add your oVirt engine certificate to your system trust root. If you don't want to, or can't add the certificate to the system trust root, you can also directly provide it to the client. Finally, you can also disable certificate verification. Do we need to say that this is a very, very bad idea? The configured tls variable can then be passed to the New() function to create an oVirt client. This library attempts to retry API calls that can be retried if possible. Each function has a sensible retry policy. However, you may want to customize the retries by passing one or more retry flags. The following retry flags are supported: This strategy will stop retries when the context parameter is canceled. This strategy adds a wait time after each time, which is increased by the given factor on each try. The default is a backoff with a factor of 2. This strategy will cancel retries if the error in question is a permanent error. This is enabled by default. This strategy will abort retries if a maximum number of tries is reached. On complex calls the retries are counted per underlying API call. This strategy will abort retries if a certain time has been elapsed for the higher level call. This strategy will abort retries if a certain underlying API call takes longer than the specified duration.