The code has a runtime dependency which is not available in our development environment (and is available in test and prod). It's expensive to actually test for the dependency, and I want to test for the environment instead.
if (isDevEnvironment) {
// fake it
}
else {
// actually do it
}
Without using appSettings, what code/technique/test would you use to set isDevEnvironment?
Example answers:
check machine name (partial or full)
check for running instance of Visual Studio
check for environment variable
I'm hoping for a test I hadn't considered.
You should try to not test your environment in the code! That's why dependency inversion (and then injection) has been invented for.
Draw some inspiration from NewSpeak, where where the complete platform is abstracted in an object and passed as parameter down the chain of method calls.
The code you provided (if (isDevEnvironment) ..) smells with test code in production.
Without using appSettings, what code/technique/test would you use to set isDevEnvironment?
Generally, Dependency Injection.
But also the the possible Solution in the link provided.
You should not check the environment, instead you need to provide the environment.
You've hit upon the major techniques. At my current job, we use the Enviroment variable technique.
At a previous job, all servers had three NIC's, there was the public front end, the middle tier for server to server traffic, and the back end Network Operations would connect to.
There were on different IP subnets. It made it easy to detect where something was coming from, but also who where was it.
Example:
10.100.x.xxx - Production Subnet
10.100.1.xxx - Back
10.100.2.xxx - Middle
10.100.3.xxx - Front
10.0.1.x - Development Subnet
This required nothing to be installed special on the servers, just code detection and then caching.
I prefer to do this:
if(Properties.Settings.Default.TestEnvironment || HttpContext.Current.Request.ServerVariables["Server_Name"] == "localhost")
{
// do something
}
Related
There is a new JSWASM approach that allows saving to SQLite (the fast OPFS way) in the browser via a javascript Worker. A sample is here that is (sort of) for a Chrome extension. Ideally, it would allow saving from the background.js, but it's unclear whether a worker can be called from there in MV3 based on this and this. Does anyone have a simple working example closer to my use case, which is saving content from the user's active tab to a SQLite database? Thanks.
The OPFS depends on the createSyncAccessHandle() method, which is exposed in Worker threads. The usual feature detection goes like this:
if (self instanceof WorkerGlobalScope && 'createSyncAccessHandle' in self.FileSystemFileHandle.prototype) {
// OPFS in `Worker` is supported!
}
Now an extension service worker (as currently implemented in Chrome) is an instance of ServiceWorkerGlobalScope, so the API is not supported there.
Unfortunately at the moment the only choice is to open an extension page and then run the OPFS code from there.
We have a microservice that needs to be integration tested (real calls, but no network communication with anything outside of the test namespace in kubernetes) in our pipeline. It also relies on an external gRPC server which we have no control over.
Above is a picture of what we'd like to have happen. The white box on the left is code that provides the Microservice Boundary with 'external' data. It then keeps calling the Code via REST until it gets back the proper number of records or it times out. The Code pulls records from an internal database, as well as data associated to those records from a gRPC call. Since we do not own the gRPC service, but are doing integration tests, we need a few pre-defined responses to the two gRPC services we call (blue box).
Since our integration tests are self-contained right now, and we don't want to write an entirely new actual gRPC server implementation just to mimick calls, is there a way to stand up a real gRPC server and configure it to return responses? The request is pretty much like a mock setup, except with an actual server.
We need to be able to:
give the server multiple proto files to interpret and have it expose those as endpoints. Proto files must be able to have different package names
using files we can store in source control, configure the responses to each call
able to run in a linux docker container (no windows)
I did find gripmock which seemed almost exactly what we need, but it only serves one proto file per container. It supposedly can serve more than one, but I can't get it to work and their example that serves two files implies each proto file must have the same package name which will likely never happen with our scenarios. In the meantime we are using it, but if we have 10 gRPC call dependencies, we now have to run 10 gripmock servers.
Wikipedia contains a list of API mocking tools. Looking at that list today there is a commercial tool that supports gRPC called Traffic Parrot which allows you to create gRPC mocks based on your Proto files. You can give it multiple proto files, store the mocks in Git and run the tool in Docker.
There are also open-source tools like GripMock but it does not generate stubs based on Proto files, you have to create them manually. Also, the project up to today was not keeping up to date with Proto and gRPC developments i.e. the package name issue you have discovered yourself above (works only if the package names in different proto files are the same). There are a few other open-source tools like grpc-wiremock, grpc-mock or bloomrpc-mock but they still lack widespread adoption and hence might be risky to adopt for an important enterprise project.
Keep in mind, the mock generated will be only a test double, it will not replicate the full behaviour of the system the Proto file corresponds to. If you wanted to also replicate partially the semantics of the messages consider doing a recording of the gRPC messages to create the mocks, that way you can see the sample data as well.
Take a look at this JS library which hopefully does what you need:
https://github.com/alenon/grpc-mock-server
Usage example:
private static readonly PROTO_PATH: string = __dirname + "example.proto";
private static readonly PKG_NAME: string = "com.alenon.example";
private static readonly SERVICE_NAME: string = "ExampleService";
...
const implementations = {
ex1: (call: any, callback: any) => {
const response: any =
new this.proto.ExampleResponse.constructor({msg: "the response message"});
callback(null, response);
},
};
this.server.addService(PROTO_PATH, PKG_NAME, SERVICE_NAME, implementations);
this.server.start();
Is there anyway to determine if the Rocket.chat app is running in desktop or browser?
Thank you in advance. :)
You can look at server environment variables using a line like this:
console.log(process.env.TZ);
If you need to access that from the client, you can do this in your client code:
console.log("TZ = "+Meteor.call("getEnv","TZ"));
and in your meteor methods (in the server folder)
Meteor.methods({
getEnv: function(varname) {
return process.env[varname];
},
Obviously use this with care. It is a generic method that may present a security hole. If you want to make it more secure, just write a specific method where you don't pass the environment variable name, to prevent any kind of malicious attack.
I am currently working on a project where we need to test the database packages and functions.
We need to provide the input parameters to the database package and test the packages returns the expected value, also we want to test the response time of the request.
Please advice, if there is any tool available to perform this or we can write our test cases in Junit or some other framework.
Which one will be best approach?
I've used a more native approach when I had to do DWH testing. I've arranged the Test framework around the Dev data integration framework that was already in place. So i had a lot of reusable jobs, configurations and code. But using OOP like you suggest
write our test cases in Junit
is a way to go too. But keep in mind that very often the DWH design is very complex (with a lot of aspects to consider) and interacting with the Persistence layer is not always the best candidate for testing strategy. A more DB oriented solution (like tSQLt) offers a significant performance.
Those resources helped me a lot:
dwh_testing
data-warehouse-testing
what-is-a-data-warehouse-and-how-do-i-test-it
My framework Acolyte provides a JDBC driver & tools, designed for such purposes (mock up, testing, ...): http://tour.acolyte.eu.org
It's used already in some open source projects (Anorm, Youtube Vitess, ...), either in vanilla Java, or using its Scala DSL.
handler = handleStatement.withQueryDetection(...).
withQueryHandler(/* which result for which query */).
withUpdateHandler(/* which result for which update */).
// Register prepared handler with expected ID 'my-unique-id'
acolyte.Driver.register("my-unique-id", handler);
// then ...
Connection con = DriverManager.getConnection(jdbcUrl);
// ... Connection |con| is managed through |handler|
I have a scenario that I want to use the Agent and USM component to implement the customer command to control a computer, but I donot want to install an application or a service,
how can i reach this goal?
thank you very much!
Steve
You can install an empty service, one that does not actually run anything. This is often called a 'recipe about nothing'. It should look something like this:
service {
name "empty"
type "WEB_SERVER"
lifecycle {
locator {
NO_PROCESS_LOCATORS
}
}
}
Add your custom commands here and you can run them from the Cloudify CLI/REST API as usual.
Note the use of the NO_PROCESS_LOCATORS directive - this tells the USM not to perform any process liveness scans.