Resting Hystrix from integration test - hystrix

I am trying to write an integrations tests for an rest service "A" with restAssured and SpringBootTest , and the A service is calling an other Service "B" in an Hystrix command , I would like to reset hystix after each test from my test
I tryed Hystrix.reset(); and HystrixPlugins.reset(); but it doesnt work, I guess that this mehods have to be called fome the app code not from the test

Related

Testing in AngularJS : How do I test the backend response of my API's?

I am new to testing in AngularJS and just started to use testing using Karma and jasmine for a particular use case. Actually, I am a front end developer and the backend API's keep changing as the system is under migration. So I wanted to implement a test on service wherein I can catch response from the actual API and test the response where I have the same data all the time as the database is exported and is in the consistent state.
Is there a way to do it? Because all articles I have read they mock the response of the API and then test the individual methods written. Or do I have to use protractor for E2E testing?
When you run tests with karma, your backend will be mocked as soon as you load angular-mocks.js (see https://docs.angularjs.org/api/ngMock/service/$httpBackend). This is what we want because we need unit tests to run quickly without having to run a backend and database.
If you need to test the interaction between your app and the real API, you need to do E2E tests with protactor, as in this kind of test, the backend is running.
Now, if you need to test the real API output, it is - in my humble opinion - the work of the backend developer. Having that said, you can of course test it yourself, but it has nothing to do with AngularJS. I'm not a NodeJS developer but there are tools to test API endpoint. You can look at SuperTest for example wich
provide a high-level abstraction for testing HTTP
Here is an example from their documentation :
var request = require('supertest');
var express = require('express');
var app = express();
app.get('/user', function(req, res) {
res.status(200).json({ name: 'tobi' });
});
request(app)
.get('/user')
.expect('Content-Type', /json/)
.expect('Content-Length', '15')
.expect(200)
.end(function(err, res) {
if (err) throw err;
});
Many people forget that Karma is not specific to Angular. It is made to run tests on JavaScript code, regardless of the framework you may or may not use. So, you can run tests with Karma that do not use Angular or Angular Mocks and that interact with a database. These types of tests are called integration or functional tests (there's a fine line that separates the two, depending upon how you look at it) and they should be included in every project. I have seen tests of this nature use Jasmine, and I have seen them use Mocha. The choice is yours. Either way, don't expect them to run as fast as unit tests since you'll be contending with network and database latency. When you run these tests in your development cycle is up to you. Since they take longer, most times they are only run on a full build or after the API/database have changed.
All of this being said, the developers that produce the API should be the ones writing/running these tests and providing you (the customer) with updated documentation.

Unit testing on an Angular app with Karma

So i'm quite new with test cases and I have a small questions (specific to my case).
I am currently developing an Angular app and started to do unit test with Karma (Mocha/Chai).
The back end of this app is a node RESTful API.
So basically, the app is a bunch of controllers and services making some basic CRUD operations.
On creation of a new user for example, I handle the verification in the html form using angular's form directives. In the server side, there is also a verification on the object received.
So generally my functions on controllers are no more then things like:
create() {
UserService.create(vm.newUser).then(callBackToDisplaySuccessOrErrorMessage);
}
It will probably sounds silly, but i'm new in this domain (test cases) and i am a little bit confused, so my first question is:
since the http calls are mocked, what is the point to do unit testing in app such as mine ?
And my second question is :
how to unit test basic app like in my case in a proper way ?
To clarify your doubts:
1. Mocking is used to test the communication.
While writing spec for your controller who are more interested in verifying whether a call to userService.create is invoked with expected parameters or not. Similarly you will mock the response from service if any. So you have validated the functionality of Controller-communicating with- Service.
Now when you write spec for service, yes http calls are mocked, but still you are validating the http url, expected method to be invoked like GET, POST etc, parameters to be passed. You only mock the expected success/failure response and validate your handlers for the same.

How to setup endless testing with Protractor with SauceLabs?

I have a webserver with protractor tests on it, i want to setup endless testing with saucelabs.
They say just add sauceLabs user and key to the conf.js file of protractor.
Should I use cron or something else to make it endless testing loop ?
This is something you should not solve on the protractor level.
Use jenkins or other continuous integration servers, or simply schedule it in cron.

How can I setup my environment to use h2 for tests and mysql for development?

I'm using the default configuration for the yo jhipster generator except that I'm using mysql as my "dev" database. When I run mvn test my tests succeed with no failures.
However, I found that if I ran tests a second time, the suite would fail since it would run against the "dev" database...that wasn't 'rolled back' or 'reset' after the previous test run. I would rather have expected it to run against an in-memory h2 database as configured in src/test/resources/config/application.yml that would be reset after each run.
How can I setup my environment with h2 for tests and mysql for development?
Thanks
I'm not sure if this is the "right" way to solve this but I was able to get my tests to pass on repeated runs by creating a new profile "test".
I then had to do 2 things:
1) change spring.profile in src/test/resources/config/application.yml to "test" instead of "dev" (to make the test application.yml different from the dev one)
2) use #ActiveProfiles("test") instead of #ActiveProfiles("dev") in my tests
The test application.yml uses an h2 database and is reset between runs as desired.
Note: I also had some success with successive test runs without creating a new profile by annotating my test classes with:
#Transactional
#TransactionConfiguration(defaultRollback = true)
as...
At the end of the test the transaction will be rolled back and the data discarded leaving a fresh environment for the next test to execute.
see https://spring.io/guides/tutorials/data/3/

How to work with authentication in local Google App Engine tests written in Go?

I'm building a webapp in Go that requires authentication. I'd like to run local tests using appengine/aetest that validate the authentication behavior. However, I do not see any way to create an aetest.Context with a dummy user. Am I missing something?
I had a similar issue with Python sdk. The gist of the solution is to bypass authentication when tests run locally.
You should have access to the [web] app object at the the test setup time - create a user object and save it into the app (or wherever your get_current_user() method will check).
This will let you unit test all application functions except authentication itself. For the later part you can deploy your latest changes as unpublished google app version, then test authentication and if all works - publish the version.
I've discovered some header values that seem to do the trick. appengine/user/user_dev.go has the following:
X-AppEngine-Internal-User-Email
X-AppEngine-Internal-User-Federated-Identity
X-AppEngine-Internal-User-Federated-Provider
X-AppEngine-Internal-User-Id
X-AppEngine-Internal-User-Is-Admin
If I set those headers on the Context's Request when doing in-process tests, things seem to work as expected. If I set the headers on a request that I create separately, things are less successful, since the 'user.Current()' call consults the Context's Request.
These headers might work in a Python environment as well.

Resources