Asking this question because I am trying to figure out the framework which is most widely used for integration testing akka-http. How to automate those tests in Jenkins? Probably a rookie question but ideas are appreciated. Thanks
EDIT from comments:
What have you tried so far? So far I tried implementing 1. Jest 2. Using Testkit, IntegrationPatience Where are you stuck? Both the approaches doesn't look like standard to me and since I have app deployed in multiple locations, I am trying to understand if there is any framework out there which I can use to setup. The app is deployed to multiple data centers which may have different environment variables.
There are a bunch of ways to test a microservice developed using akka-http:
Unit testing
Functional / Integration testing
E2E testing
Load testing
Unit testing using route-testkit (https://doc.akka.io/docs/akka-http/current/routing-dsl/testkit.html)
Functional testing & E2E testing using Akka HTTP client API (https://doc.akka.io/docs/akka-http/current/client-side/index.html) with API contracts you can validate the status codes and response body.
Load testing can be achieved using a bunch of tools, specifically in Scala you can take a look at Gatling.
Related
Let's say I have a frontend application written in Angular and a backend application written in Django and Django Rest Framework. I created unit tests for backend application (with pytest) and I'm about to create some functional tests for the frontend application. The thing is that the frontend app needs access to the backend app in order to work correctly. I can write some mocks to handle that, but I am not sure if this is the best way to do that.
My question is, what is the best way to handle that? Should I use a single git repo for both applications or maybe a better way is to use two repositories, but then how to handle the tests for frontend application?
I was also thinking about using selenium with pytest, but then I would have to use a single repository. I am a little bit confused and would really use some good advice. Thanks!
Unit tests as the name suggests is testing separate units of the code in isolation. Meaning that it does not have to depend on any other part, else, you wouldn't know if the test is failing for that particular unit or the units it depends on.
As a result, all tests should mock the request to the backend and return valid responses (or invalid, if you're testing for error handling). The same applies to any other external service that the unit depends on.
I'm attempting to learn AngularJS. One of the things that attracts me is its claim of separation of concerns and unit testability. So it defeats me completely to understand why I should need to install Node.js, or any web server, to test (say) an AngularJS controller which does no DOM manipulation or call out to any web services.
Can anyone give me a definitive bare-minimum list of what is required to unit test AngularJS code?
I'm going assume that you understand the difference between end-to-end testing and unit testing in Angular, so you're only asking about what it takes to do unit testing, right?
Basically you're going to need pretty much everything that comes with the seed project. The seed project uses Karma as the test runner to execute the javascript that you've written. Step 02 of the AngularJS Tutorial (found here) walks through writing some simple tests and executing them using Karma. Everything required to do that comes with the seed-project.
Those required things are:
An angularjs app
Node.js (installed)
Karma
Some jasmine-style unit tests
If you don't want to use the seed project, you can use Step 02 of the tutorial as a spring board and just follow the Karma docs to download and install Karma and get it running.
I hope that helps.
for a front-end developer, who writes angular code, what part of a javascript front-end project should I be unit testing? I find it needless to test a lot of the code, and my biggest hang up is which part of the angular services needs to be tested? if $httpBackend is a mock call, what's the point of calling it?
As your project grows in complexity, you may find that your angular application is doing a lot. Angular's design allows the client to take a lot of the responsibility for processing and rendering data from the server.
Yes, I agree, you shouldn't test anything but your own code. So, writing tests for $http is useless. However, if you are expecting the server to return a specific JSON contract, and you want the assurance that you are mapping that correctly to a structure that you will use in your angular app, that is worth testing. Further, if you are making calculations in services or controllers, that logic is worth testing.
Angular itself is set up to support TDD because it has a nice separation of concerns between the view, controller and services (even directives can be compiled and tested). All of the javascript code that you write is a good candidate for test coverage. So, IMHO, you should be unit testing your directives, your controllers, and your services. You can get as detailed as you want to give yourself the assurance that your code is solid.
I am still trying to totally understand BDD and I am facing some doubts.
From my little experience, I have been using it to automate user acceptance test and I would like to know if it's possible to use it to test a web API, without UI.
In the past I've used BDD using the given-when-then jargon and mapping the steps to UI interactions. I've done this with Specflow in ASP.NET or cucumber/capybara in ruby on rails.
So for example we could have scenarios like this:
Given I am in the home page
When I click login button
Then I should see the login page
The current project I am working at is different. We are implementing an API based in web service which would be consumed by different type of clients. Like an iphone app, android app and an asp based web client. So our main focus is based in the back-end and just that.
In this case, the tests can't be faced from the UI point of view. So our end-to-end tests are based in our service endpoints. We pass some input arguments to a service calls and check the outputs.
Can we do this using BDD? Is this right?
or maybe it would be better to use a different thing like FitNesse?
Hmm.. is using FitNesse doing BDD?
I think you can do what your writing about in BDD. I'm not sure if those 2 links about testing of webservices with SpecFlow will help you but take a look on them if you haven't seen it yet.
http://codedetective.blogspot.co.uk/2012/10/testing-webservices-with-specflow.html
http://www.creamdog.se/blog/2011/02/24/webservices-automated-tests-using-specflow-and-babelfish/
Have a look at Karate, web service testing framework by Intuit. It's recently being open sourced. It has the capability of handling API dealing with HTML, JSON, XML, GraphQL queries and is built on top on cucumber.
Simple intro here : https://medium.com/blueprint-by-intuit/karate-web-services-testing-made-simple-366e8eb5adc0#.qnpy5gagt
We have a monolithic application written in Visual Dataflex, and various complementing applications written in other (.NET) languages. They all share the same database, and need to follow the same business logic. One way to facilitate unified business logic across these is to provide web services as an interface for testing.
Of course, for this to work, we need a good framework for testing web services. Any suggestions? For example, can Cucumber do this "out of the box"?
I'm assuming you're talking about Soap web services. You can use Soap4R to talk to a Soap web service. Wrapping this all up in Cucumber scenarios should work fine.
SoapUI is a pretty nice product for creating webservice tests, and they're easily callable via junit or just via the command line. It's also got some stuff for creating load tests as well.
They've got an opensource version as well as a professional version.