At the moment, HyperTest is a closed-source project. However, we welcome your feature requests! Simply submit them to our support team, and we'll do our best to accommodate them in future updates.

Currently, HyperTest treats APIs with different versions as unique entities, without grouping them for version control. This means there's no specific provision to manage versioning of API mocks to align with API version changes.

HyperTest is not designed specifically for load testing, other popular solutions specialize in this area. You might consider exploring tools like Apache JMeter, Gatling, LoadRunner, K6, or Locust for conducting load testing effectively. These tools offer robust features specifically tailored for load testing scenarios.

Indeed! HyperTest manages authenticated API calls by capturing the headers containing the authentication token. To address token expiry, we've customized the behavior of the jsonwebtoken library by patching it on runtime so that it doesn't throw errors when encountering expired tokens. This ensures that your authenticated routes remain valid at all times.

There are two scenarios in which you could encounter this issue: 1. You’ve added a new outbound call to your existing API and we haven’t captured that mock. In this case, you should re-record a new API interaction that has this outbound mock and delete the older one. 2. HyperTest was not able to identify the mock properly from the available mocks for the test. In this case, you should reach out to the support team to raise this issue.

You can reach out to our support team via email [[ INSERT_EMAIL_ID ]].

App crashes after integrating HyperTest SDK: There could be several reasons for App crashes, lets discuss one by one: 1. Incorrect configuration: Please make sure you provide the right configure while intializing HyperTest SDK, e.g., serviceId & apiKey. 2. Using unsupported version of programming language or Run time environments: As of now HyperTest supports Node.js versions >= v14. 3. Your application depends on some 3rd party service to provide boot configuration: If you're calling an external service to fetch boot configurations then it could cause issues as we would try to mock all the external calls and not having relevant config at boot during a test run might cause unexpected issues. To solve this you should put this call inside an unmocked context so that the call goes through all the time, you can find more about it here. 4. Unknown error originating from your dependency: If you're getting this error only when running you app with HyperTest SDK in place then it is possible that we have instrumented this dependency and it has some bug which is causing this error, in such case please report this issue to our support team and we will try to resolve it as soon as possible. 5. Cannot start server because port is not available: HyperTest internally spins up two servers and they listen on available ports of these ranges: SDK server: 3001-3010 and CLI server: 4001-4010. You can verify if your application is using the same port as one of these server by passing this env variable to HyperTest CLI: "DEBUG=ht*", this will log the ports being used. If found same port is being used then please change port of your end to solve this. Seeing MOCK_NOT_FOUND during test runs: There are two scenarios in which you could encounter this issue: 1. You’ve added a new outbound call to your existing API and we haven’t captured that mock. In this case, you should re-record a new API interaction that has this outbound mock and delete the older one. 2. HyperTest was not able to identify the mock properly from the available mocks for the test. In this case, you should reach out to the support team to raise this issue. Requests not getting captured: There could be several reasons for this, lets discuss one by one: 1. Use of incorrect serviceId: Please make sure you've copied the correct serviceId from the dashboard and you're viewing requests of that service only. 2. Initializing SDK before everything else: HyperTest works by monkey patching your dependencies, it is mandated that you initialize hypertest before doing anything in your entry file so that it patches all the dependencies before being used, if we dont do this then you might see missing mocks or requests. 3. Issue with Opentelemetery Trace Exporter: To debug further you can try setting env variable "DEBUG=ht*" to see debug logs by HyperTest SDK. If you see any log that starts with: "HT-ERROR: Failed to export traces:" then it's an issue from our end. In this case, you should reach out to the support team to raise this issue. Seeing exceptions in CLI test results: If you're seeing that exception count is more than 0 then you should look at the logs for app crashes and you will see the id of the test case under question, you can view the particular test case on the dashboard and figure out why it is crashing the app. If it's a stale request that doesn't resonate with the current state of your application then you can discard it. If this exception is unexplainable and you don't find a test case id in the logs then you can try turning on the debug logs for the CLI by setting this env variable "DEBUG=ht*" to see the detailed logs. No mocks for expected outbound calls: Usually, this means that we have not provided support for this dependency or there's a bug in the HyperTest instrumentation, in any case, please reach out to the support team to raise this issue.

You will see HyperTest SDK logs in your Applications “stderr” output for enhanced debugging you can turn on debug logs by setting this environment variable “DEBUG: ht*”.

You can accept changes found in the test report to update the mock, if they are not being used then accepting changes will remove that mock from the test, but you cannot manually update it. If a test seems outdated, you can record a new one and delete the old one from the dashboard.

First, verify if the dependency responsible for the outbound call is supported by HyperTest (check here). If it is, there may be a bug, and you should contact our team for assistance. If it's not supported, please submit a request to our team for adding support for that specific dependency. We'll prioritize adding support as soon as possible.

HyperTest doesn't offer distributed tracing, meaning it doesn't capture all traces it receives. However, it does keep a record of unique server requests (test cases) and tracks the flow of interactions between different microservices. While this specific feature isn't available yet, it's planned for future implementation.

Absolutely! HyperTest seamlessly integrates with microservices architectures. Developers can easily visualize their service mesh and the interactions between services. Plus, they'll receive alerts about any new changes made to upstream or downstream service contracts. Although this feature isn't currently available, it's on the roadmap and will be implemented soon.