The complexity and interaction of software applications used in companies has increased dramatically in recent years. When releases are rolled out today, some of the new functions are related to the exchange of data with other applications. We also notice this in software testing: The focus of testing has expanded from pure system testing to the area of integration testing. Therefore, mocks are also used.
We work in a test centre and carry out the comprehensive integration test for our customers on their complex application infrastructure. Therefore, we build the test environments to match the productive environment. So why do we need mocks if the integration test environment already has all software components?
This way of thinking is partly correct, but different focuses are set on the different staging levels during testing. Mocks are used less in system testing, since this is where the software functions are tested. Instead, mocks are more often used in integration testing. However, since it is not always possible to test the complete message flow, communication at the interface is tested as an alternative.
If 3 components are tested in the integration test, which are located directly one after the other in the message flow, it cannot be guaranteed one hundred percent that the procedure will run without problems when using all 3 software components. It is possible that the respective errors of the components could falsify the message flow and be corrected afterwards, the error is quasi masked. Therefore, we put mocks at the respective ends of the components to get specific inputs and outputs.
To explain the described problems and peculiarities of a mock, we use a residual service as the application to be tested. The Rest-Service should be able to perform a GET and a POST command. If our component would now ask the mock for personal data with a GET command, we could configure our mock to return standardized answers or perform simple calculations on POST commands.
Using Microsoft Visual Studio, you could quickly create a WebAPI project in C# that has the basic function of a rest service. The methods of the controller only have to be adapted and you have a working Rest-API available.
File > New > Project > Visual C# > Web > Web Application
If you look at the WebAPI controllers, you can see that certain URLs call functions within the API. In this example we use a small WebAPI that is used as a hero database.
[Route("api/hero/get")]
[HttpGet]
public Iherolist Get()
{
Console.WriteLine("Return of all heroes of the database");
return heroRepository.GetAllHeroes();
}
[Route("api/hero/add")]
[HttpPost]
public string AddHeroDetails([FromBody]Hero hero)
{
//AddHeroToDatabase(hero);
return "The hero with the name: " + hero.Name + hero.Klasse + " has been added";
}The route describes the URL path to call the HttpGet(GET command) or HttpPost(POST command) function.
Example: http:localhost/api/hero/add
Once you get the Rest API up and running, you can use an API tool (Postman) or a browser to send different Rest commands to the URL. When a POST command is sent to the Rest API, the service accepts it and recognizes from the URL that the function AddHeldenDetails() should be called. The function takes the sent data and adds it to its database. In response it returns the return value of the function. In this case the confirmation about adding the desired hero.
POST command:
POST /api/hero/add HTTP/1.1
Host: localhost:53521
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Postman-Token: b169b96f-682d-165d-640f-dbcafe52789e
{ „name“:“Maria“,“class“: „lord“,“age“:68,“level“:57 }Answer:
The heroine with the name: Maria was added
We have now added the heroine Maria to the database with our POST command. Now you can retrieve the stored heroes with the GET command. Here is an example of the format of the GET command, which is sent to the Rest-API with the corresponding response of the API:
Query:
GET /api/hero/get HTTP/1.1
Host: localhost:53521
Content-Type: application/json
Cache-Control: no-cache
Postman-Token: b3f19b01-11cf-85f1-100f-2cf175a990d9
Answer:
{"theList":
[
{"name":"Lukas","class":"healer","age":"25","level":"12"};
{"name":"Martin","class":"warrior","age":"30","level":"13"};
{"name":"Gustav","class":"thief","age":"18","level":"19"};
{"name":"Maria","class":"lord","age":"68","level":"57"};
]
}In the answer, you can see that the heroine Maria has been added to the list and can now be called up at any time.
Now we know how the Rest-Services work, which input leads to which output. With this information we can start building a mock. I will deal with this topic in the next part.
That was “Mocks in the Test Environment Part 1” … Part 2 follows 🙂
This post was written by:
