Always get this question:

How to test asynchronous tasks?
How to test the asynchronous interface?
Can automation be used to ensure that asynchronous tasks are executed?
Is there any guarantee that the execution will be successful?

Received such a question, in fact, everyone's question is common, so just sort out some of my views for reference.

How to test asynchronous tasks, how to test?

It's actually very simple. How about we want to test this? In fact, we must first understand what is an asynchronous task? What are asynchronous tasks usually used for?

Asynchronous tasks are actually when synchronization cannot satisfy the current task, and it is handed over to asynchronously to perform these time-consuming tasks, and the thread does not need to be blocked to continue doing other things.

So based on this, the popular saying is to do it in the background at the same time, without delaying the continuation in the front desk,

Understand what the asynchronous task we want to test is used for? How to achieve? What business problem does it solve?

We can all communicate with the children's shoes of our technical team to understand what has been done? How to achieve it? What problem did it solve? So we know how it works, how to achieve it, and why do we do it? Then it is how to test, the purpose of testing is to ensure the accuracy of technology implementation.

Get to know these three well. So next, we know how to test? How to test it actually focuses on the task itself. What was executed? What did you do? What changed in the end? In fact, when communicating with technology, he explained to us the implementation process, many implementation points, and the implementation process is the testing point we discovered.

Listed below, the usual asynchronous tasks will have the following changes: 1. log log 2. file changes 3. database changes 4. redis changes, etc.

Then knowing these aspects can be seen, you can do some automated support.

1. Log log, after executing the interface, check whether there is output in the log.
   In addition to manual viewing, you can also automatically obtain the output of the log log to determine whether to execute
2. File changes If the file is operated, then the file will definitely be operated after the operation.
   For example, simply, after the file changes, the operation time will change,
   Then we can see if the latest file is relevant, we can only check if there is this file at the corresponding time,
   In such a quick judgment, the reading and writing of files can also be automated to find out whether these files have changed.
3. Database changes After the asynchronous task operation, the corresponding data will change,
   Then we need to obtain the corresponding data before the execution, the call interface has, after observing the execution,
    Whether the data changes.
4. Redis changes, the operation of this combined database is similar, to check whether the data has changed.

These four scenarios can all be realized in an automated way, or let the development provide some necessary assistance for verification.

In fact, many questions are common, when we don't know how to test. How to do similar work? How to test it?

Very simple trilogy:

 1. Determine mission objectives

 2. Find a testable solution (communication) 

3. Execute the test to collect the results.

The trilogy is very simple, and the second is the hardest, requiring a lot of practice and a lot of communication. For myself, it is also a good improvement.

How to find a quick verification solution and provide ideas for solving problems is a good verification of the test engineer 's ability. If the technology is difficult, we can split it into one, two, and three to realize it.

What I have listed are just some simple ideas, and specific problems still need to be analyzed in detail. Only by doing more actual combat can we find the best solutions when encountering problems.