I am really interested in different aspects of testing. I hope you can really read this and just give me your ideas if you have experience with this. Let's break down.
Fact 1: It's said that when we write a test from user perspective(going to uri, and getting results and if user sees the correct result, then test is right). They say this is called functional testing.
Sum up 1: So turns out when we write tests for controller, it's always functional as we must make the request to endpoint and observe the result. SO writing tests for controllers are always functional tests. Is that right?
==========================================================================
Fact 2: So, Integration testing is not controller testing. Let's imagine we have some functions (not controller functions) in our app. For example in our helper classes or models. and we want to test those functions like integration testing. So we won't mock anything and just test it.
Sum up 2: So, integration testing can be done on functions that are not controller functions, are written on other places(where request doesn't need to be done) and they must use external dependencies. By external dependencies, anything can be thought (such as file,database or another class itself) . Is that right?
==========================================================================
Sum up 3: what if I have just an api and instead of returning views, I return json and status codes from controllers. If i write test for controllers, it will still be called functional tests. right?
Interesting question. I believe it depends on how you test the controller. Let's start with a couple of definitions of different types of testing. These definitions broadly follow your two facts.
Let's take the example of an e-commerce platform and the Controller for a checkout.
Controller - unit testing
This is where we have to consider the controller in isolation. So we want to mock the request from the user. For example, if you are using the Spring Framework you can make use of the library to mock http requests.
Controller - integration testing
To be an integration test we need to consider the interaction of two parts of the system. In our shopping basket example, we could mock the http request as above but test the interaction between the shopping basket and the checkout code.
Controller - functional testing
For functional testing, we need to consider the end to end scenario of the user clicking on the UI and using the shopping basket.
In summary, if you are testing your controller using something that is mocking the HTTP request then it is most likely unit or integration testing. If you are testing the controller using selenium or a user clicking on a UI then it is most likely functional testing.
Related
I am using the nestjs framework and I want to write the unit test cases for every service and controller.
I have gone through many examples on google but not found any solution.
Actually, I want to play with the real database without mocking any service and the controller.
Any help would be appreciated.
If you're working with a real database connection, you're doing integration tests, not unit tests. A unit test mocks out the logic that isn't being immediately tested (external libraries, database calls, HTTP requests, etc), whereas an integration sometimes tests these, and sometimes just tests between classes without mocking those relationships.
There's a large repository of samples you can find here. This repo has unit and e2e/integration tests. Without knowing more on what you want to test, there's not really more anyone can say other than "Generally here's how you do it" which the docs already cover pretty well
I am exploring individual microservice testing & came across a good guide https://martinfowler.com/articles/microservice-testing/#testing-component-in-process-diagram. This post suggest there is a way to test the individual microservices "in-process".
Which means the test & service will execute in same process, it also provides the lib which can be used. However I am not able to understand following things
1) How exactly "in-process" testing will work in microservice architecture
2) Any pointers on how to use "inproctester" lib.
Thanks
This can be accomplished by hosting your API in process, interacting with it - in process - whilst using test doubles at the edges of you API, or (put another way) using test doubles for external collaborators.
This allows an API (and its core behaviour) to be tested in a test (unit/integration depending on opinion) without ever hitting a network or database or filesystem.
This testing will provide coverage but obviously not all the coverage you need
In .NET core you can use TestServer included in the Microsoft.AspNetCore.TestHost package.
If your API is simple enough you can perhaps reduce your types of testing (N.B. I am not suggesting reducing coverage)
This approach is alluded to in the slide deck you mention on page 8/25
Paraphrasing. If the logic in the API is small, component tests may be favourable to isolated and sociable unit tests
This approach is also recommended in the Spotify "Honeycomb" style testing. They call component testing of an API Integration testing (which coincidentally Microsoft also call it when they are using TestServer in their tests (second link for concrete examples)
https://labs.spotify.com/2018/01/11/testing-of-microservices/
https://learn.microsoft.com/en-us/aspnet/core/testing/integration-testing
I think that the thrust of the approach (regardless of its specific name) is that in process testing is fast and external collaborators are replaed with test doubles.
One thing worth noting is that "out of process" component tests are basically end to end tests but with all external collaborators swapped out with test doubles.
These may be a bit slower than in process component tests but exercise a bit more of the "stack". I'd suggest that if you are going to end-end test anyway, I'd try and do in process component testing as much as possible.
I want to start a pet project to get confident with creating Web Applications from scratch and I want to use BDD and TDD.
I read in "Growing Object-Oriented Software: Guided by Tests" that we should start from the thinnest slice of the system that allows us to have a walking skeleton of the entire application so we have can have a quick feedback and start wondering about the production/deployment procedures.
After writing the acceptance test in BDD I would move to finer granularity tests such as Unit tests.
Imagining that the web application is about finding the superhero who is more similar to you, I would write a BDD scenario such as:
When I insert my information
Then the system should tell that the superhero I'm more similar to is "Batman"
I'm ignoring the authentication on purpose so we can focus on the main functionality of the system. This scenario assumes that there is a working infrastructure behind, so that the scenario above can be replicated automatically, end-to-end.
Assuming that I want to lay out the web application in different layers (Web Server, Application Server and Database), how can I implement this test?
Supposing I want to use Selenium WebDriver to simulate the user, what layers must be mocked and what layer is going to be tested first?
I also thought about starting from testing the API only, but that wouldn't be a end-to-end test, but we would test the application only partially.
Cucumber is a good framework for BDD. UI/Selenium tests can be a bit flakey so I would suggest less of them (see Testing Pyramid).
Personally I think I would work at the API level as you suggested for starters, then you have decoupled the UI from the app.
Write some Cucumber Integration Tests of the Application (BDD) at the API level, describing high level features. I wouldn't mock at this level, as you want to see the whole app working at this point.
Then as you implement these, use TDD, here you will want to mock out externals like File IO/Database. Once all the TDD Unit Tests are done, the overall feature should then pass. Continue until all features are completed.
Continue like this and then you have a solid set of unit tests and a solid set of Integration (feature) tests at API level.
Once done (or in parallel to get a vertical slice) start the UI using 'happy day' scenario selenium tests, all that really needs testing here is the UI code and that is correctly hooked up to the App, as the main App will be well tested already.
Just my view - Hope it helps.
I'd use Cucumber for this (but I'm terribly biased), and I would start by writing some scenarios around the core part of your application.
Some important rules to follow when writing your scenarios
Use your domain language
Only talk about WHAT you are doing and WHY its important
Don't talk about HOW you do things.
So with your superhero site you can start with thinking about things you need to do to get started.
Generally when you have discovered a resource (superhero) you will have some basic CRUD operations you can explore, so
creating superhero
editing a superhero
deleting a superhero
COMPARING a superhero ** this is your key starting point **
Lets start working on the comparing a superhero scenario
Given there are superheroes Batman and Superman
And I am like Batman
When I find my superhero
Then I should see I am like Batman
Now lets start implementing this scenario. One important thing here is to not put all your code in your step definitions. Instead make each step definition a call to a helper method.
note: all following code will be ruby
Given 'there are superheroes Batman and Superman' do
create_superhero batman
create_superhero superman
end
And now we can get into the BDD red/green testing cycle.
So we will start getting errors like No method found create_superhero and undefined constant batman. We can address these with a helper module in our step definitions.
module CreateSuperHeroStepHelper
def create_superhero(attrs={})
Superhero.create(attrs)
end
def batman
{
...
}
end
...
end
And from this code we can start working on the domain objects for our application e.g. Superhero.
To get this step working you'll have to interact with your underlying web framework. Once you have it working, in its most basic form you can move onto the next step.
Along the way you'll have all sorts of choices about what you do next. If you stick to working on this core scenario, you'll have to be clever about how you implement things. If you decide to work on scenarios that seem like pre-requisites e.g. user accounts, create superhero, enter your superhero characteristics, add a superhero characteristic. Then you should end up with tools which you can use for your core scenario (e.g. you'll have create_superhero) but it will take you longer to get to the core of your application.
There is no need to be thinking about unit tests, layers or mocking here. Thats low-level detail about HOW you do things which comes much later. So long as you have some basic competency in your web framework you should be to start exploring your domain and use BDD to create simple tools that you can use to explore your World of superheroes.
Good luck
I got this question while interviewing some companies. I don't think I answer the question well. However, based on my understanding:
The UI level testing is more about the what end user will see and would be better to use for acceptance testing.
The API level test is good for performance testing, since it's easier to simulate multiple users to access the resource at the same time. And, it's easier to look at where the problem will be.
Can anyone give me more detail about that? And when should we choose to use which type of testing?? Thanks a lot.
UI stands for User Interface. UI allows the user to interact with the application.
UI testing refers to testing graphical user interfaces, such as how user interacts with the application, testing application elements like fonts, layouts, buttons, images, colors, etc. Basically, UI testing concentrates on the look-and-feel of an application.
For more details on API testing, see:
http://www.guru99.com/gui-testing.html
API is an acronym for Application Programming Interface. API enables communication between two separate software systems. A software system implementing an API contains functions/sub-routines which can be executed by another software system.
API testing is checking API of a Software System. In order to check the API , it needs to be called from the calling software . Necessary test environment, database, server, application setup needs to be prepared before doing API Testing.
API testing is focused on the functionality of the business logic (such as a calculating total price) and it is entirely different from UI testing. It mainly concentrates on the business logic layer of the software architecture. This testing won’t concentrate on the look and feel of an application.
For more details on API testing, see:
http://www.guru99.com/api-testing.html
Eric
In few words:
UI testing is testing between users (humans in most cases) and front end or client side (aka presentation logic) of the application such as a browser.
API testing is testing between backend or server side of the application (aka business logic) and backend of another application.
Instead of going into a long explanation, where you can find volumes written on the Internet, let me give you a couple of additional keywords.
For UI testing, also look at FUNCTIONAL and EXPLORATORY testing.
For API, also look at UNIT and AUTOMATED testing.
I find this resource useful http://www.stickyminds.com/testandevaluation.asp?Function=FEATUREDETAIL&ObjectId=17275
Pick the one your boss will give you a promotion for.
Testing at the API layer enables the robust, low-noise regression tests that are essential for continuous testing. It also helps you zero in on problems that might not be evident from the UI level — for example, an error in writing the expected values to the database.
GUI Testing--testing on visible elements in pages or screens called as Gui testing.some other names to GUI are Sites testing/ front end testing/ screens testing.
API testing--Testing on invisible services functionalities called as API testing. other names to API are Services testing/ middleware Testing/SOA testing.
End-to-End Testing--testing related to integration of a site and a service is called as End-to-End testing. other names are Inter System testing/ interoperability testing.
In everyday testing, basicly there are three uses for API testing from the testers' point of view.
When an application is brand new, and the backend is ready/being developed, and there is no GUI yet, that is when API is tested. Also when the new functionality is newly developed, and is not yet deployed to the GUI ready code base. This is usually the phase of the project that most, and highest priority business requirements are implemented in the code.
When you encounter a API call error in your browser's DevTools, it could be usefull to test different API resources.
When the tester reports a defect, in the defect ticket, the developers post in the result of new fix, or operations the result of the fix/configuration in the environment, as a quick check of the isolated functionality.
But in general, once a GUI is ready, usually API testing in not needed, at least for testers. Of course for developers, it is useful to test new functionalities, as a higher level testing (integration testing) after unit tests.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Are functional testing and integration testing the same?
You begin your testing through unit testing, then after completing unit testing you go for integration testing where you test the system as a whole. Is functional testing the same as integration testing? You still taking the system as a whole and testing it for functionality conformance.
Integration testing is when you test more than one component and how they function together. For instance, how another system interacts with your system, or the database interacts with your data abstraction layer. Usually, this requires a fully installed system, although in its purest forms it does not.
Functional testing is when you test the system against the functional requirements of the product. Product/Project management usually writes these up and QA formalizes the process of what a user should see and experience, and what the end result of those processes should be. Depending on the product, this can be automated or not.
Functional Testing:
Yes, we are testing the product or software as a whole functionally whether it is functionally working properly or not (testing buttons, links etc.)
For example: Login page.
you provide the username and password, you test whether it is taking you to home page or not.
Integration Testing:
Yes, you test the integrated software only but you test where the data flow is happening and is there any changes happening in the database.
For example: Sending e-mail
You send one mail to someone, there is a data flow and also change in database (the sent table increases value by 1)
Remember - clicking links and images is not integration testing. Hope you understood why, because there is no change in database by just clicking on a link.
Hope this helped you.
Functional Testing: It is a process of testing where each and every component of the module is tested. Eg: If a web page contains text field, radio botton, Buttons and Drop down etc components needed to be checked.
Integration Testing: Process where the dataflow between 2 modules are checked.
This is an important distinction, but unfortunately you will never find agreement. The problem is that most developers define these from their own point of view. It's very similar to the debate over Pluto. (If it were closer to the Sun, would it be a planet?)
Unit testing is easy to define. It tests the CUT (Code Under Test) and nothing else. (Well, as little else as possible.) That means mocks, fakes, and fixtures.
At the other end of the spectrum there is what many people call system integration testing. That's testing as much as possible, but still looking for bugs in your own CUT.
But what about the vast expanse between?
For example, what if you test just a little bit more than the CUT? What if you include a Fibonacci function, instead of using a fixture which you had injected? I would call that functional testing, but the world disagrees with me.
What if you include time() or rand()? Or what if you call http://google.com? I would call that system testing, but again, I am alone.
Why does this matter? Because system-tests are unreliable. They are necessary, but they will sometimes fail for reasons beyond your control. On the other hand, functional tests should always pass, not fail randomly; if they are fast, they might as well be used from the start in order to use Test-Driven Development without writing too many tests for your internal implementation. In other words, I think that unit-tests can be more trouble than they are worth, and I have good company.
I put tests on 3 axes, with all their zeroes at unit-testing:
Functional-testing: using real code deeper and deeper down your call-stack.
Integration-testing: higher and higher up your call-stack; in other words, testing your CUT by running the code which would use it.
System-testing: more and more unrepeatable operations (O/S scheduler, clock, network, etc.)
A test can easily be all 3, to varying degrees.
I would say that both are tightly linked to each other and very tough to distinguish between them.
In my view, Integration testing is a subset of functional testing.
Functionality testing is based on the initial requirements you receive. You will test the application behaviour is as expected with the requirements.
When it comes to integration testing, it is the interaction between modules. If A module sends an input, B module able to process it or not.
Integration testing - Integration testing is nothing but the testing of different modules. You have to test relationship between modules. For ex you open facebook then you see login page after entering login id and password you can see home page of facebook hence login page is one module and home page is another module. you have to check only relationship between them means when you logged in then only home page must be open not message box or anything else. There are 2 main types of integration testing TOP-DOWN approach and BOTTOM UP approach.
Functional Testing - In functional testing you have to only think about input and output. In this case you have to think like a actual user. Testing of What input you gave and what output you got is Functional testing. you have to only observe output. In functional testing you don't need to test coding of application or software.
In a Functional testing tester focuses only Functionality and sub functionality of application. Functionality of app should be working properly or not.
In integration testing tester have to check dependency between modules or sub-modules.Example for modules records should be fetching and displayed correctly in another module.
Integration Test:-
When Unit testing is done and issues are resolved to the related components then all the required components need to integrate under the one system so that it can perform an operation.
After combining the components of the system,To test that whether the system is working properly or not,this kind of testing is called as Integration Testing.
Functional Testing:-
The Testing is mainly divided into two categories as
1.Functional Testing
2.Non-Functional Testing
**Functional Testing:-
To test that whether the software is working according to the requirements of the user or not.
**Non-Functional Testing:-
To test that whether the software satisfies the quality criteria like Stress Test,Security test etc.
Usually,Customer will provide the requirements for Functional Test only and for Non Functional test,Requirements should not be mentioned but the application necessarily perform those activity.
Integration testing It can be seen as how the different modules of the system work together.
We mostly refers to the integrated functionality of the different modules, rather different components of the system.
For any system or software product to work efficiently, every component has to be in sync with each other.
Most of the time tool we used for integration testing will be chosen that we used for unit testing.
It is used in complex situations, when unit testing proves to be insufficient to test the system.
Functional Testing
It can be defined as testing the individual functionality of modules.
It refers to testing the software product at an individual level, to check its functionality.
Test cases are developed to check the software for expected and unexpected results.
This type of testing is carried out more from a user perspective. That is to say, it considers the expectation of the user for a type of input.
It is also referred as black-box testing as well as close-box testing
Checking the functionality of the application is generally known as functional testing, where as the integration testing is to check the flow of data from one module to other.
Lets take example of money transfer app.Suppose we have page in which we enter all the credentials and if we press transfer button and after that if we getting any success, Then this is functional testing. But in same example if we verify the amount transfer then it is integration testing.
Authors diverge a lot on this. I don't believe there is "the" correct interpretation for this. It really depends.
For example: most Rails developers consider unit tests as model tests, functional tests as controller tests and integration tests as those using something like Capybara to explore the application from a final user's perspective - that is, navigating through the page's generated HTML, using the DOM to check for expectations.
There is also acceptance tests, which in turn are a "live" documentation of the system (usually they use Gherkin to make it possible to write those in natural language), describing all of the application's features through multiple scenarios, which are in turn automated by a developer. Those, IMHO, could be also considered as both, functional tests and integration tests.
Once you understand the key concept behind each of those, you get to be more flexible regarding the right or wrong. So, again IMHO, a functional test could also be considered an integration test. For the integration test, depending on the kind of integration it's exercising, it may not be considerate a functional test - but you generally have some requirements in mind when you are writing an integration test, so most of the time it can be also considerate as a functional test.