go.chromium.org/gae
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.
Readme
designed for testing and extensibility
(but generally it should be pretty stableish).
LUCI Go GAE adaptor code is meant to be worked on from an Chromium
infra.git checkout, which
enforces packages versions and Go toolchain version. First get fetch via
depot_tools.git
then run:
fetch infra
cd infra/go
eval `./env.py`
cd src/go.chromium.org/gae
Contributing uses the same flow as Chromium contributions.
FAQs
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.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Cyber extortion in the US and Canada hit record levels in 2023, with ransomware attacks surging and median ransom demands skyrocketing, though fewer companies are choosing to pay ransoms.
Security News
Ecma TC39 is meeting this week and has moved key ECMAScript proposals forward, advancing Deferred Import Evaluation, Error.isError(), RegExp Escaping, and Promise.try to the next stages.
Security News
Researchers have demonstrated that teams of LLM agents can exploit zero-day vulnerabilities with a 53% success rate, and the costs of using AI to do so are rapidly becoming more affordable than hiring a human penetration tester.