coffee/googletest
1
0
Fork 0
mirror of https://github.com/google/googletest.git synced 2025-12-06 16:57:00 +08:00
Code Issues Packages Projects Releases Wiki Activity

Copy for convnetional test

Browse Source
This commit is contained in:
John Graley 2024-02-20 16:02:00 +00:00 committed by GitHub
parent f5b9a9239c
commit 03265e4aed
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 14 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
coroutines/docs/testing-with-two-computers.md
View File

@ -1,16 +1,23 @@
# Testing With Two Computers # Testing With Two Computers
_This is a simplified overview of conventional and coroutine-based unit testing. We explore the steps taken by a convnetional test and then present the same test in a coroutine model. We use an analogy with computers that can "only do one thing at a time" and then discuss how coroutines fit in at the end._ _This is a simplified overview of conventional and coroutine-based unit testing. We explore the steps taken by a convnetional test and then present the same test in a coroutine model. We use an analogy with computers that can "only do one thing at a time" and then discuss how coroutines fit in at the end._
## Conventional testing, using one computer ## Conventional testing, using one computer
For this exercise, we will assume that the computers illustrated can only run a single "program" at a time (but see [footnote](#Footnote)). For this exercise, we will assume that the computers illustrated can only run a single "program" at a time. Therefore, whenever code calls a function, the computer is committed to running that function to completion before it can do anything else[^1].
The computer is running a test case, which is a section of code written by a test engineer, against an API provided by a testing framework. To begin with, the test uses this API to fill in a kind of _checklist_ (data structure) with information about what function calls should come _out_ of the code-under-test.
![My test case makes a checklist of events that I will expect during the test.](/coroutines/docs/images/current_1.png) ![My test case makes a checklist of events that I will expect during the test.](/coroutines/docs/images/current_1.png)
Text after Having filled in the checklist, we are now ready to begin the test proper. We use a coding practice called _dependency injection_ to ensure that some or all of the _outgoing_ function calls from the code-under-test actually come to us and not their original intended destination. There are a few different ways to do this, and the best option generally depends on the programming language in use. We implement this and call the code-under-test.
![I am starting the code-under-test, with an injected dependancy back to me.](/coroutines/docs/images/current_2.png) ![I am starting the code-under-test, with an injected dependancy back to me.](/coroutines/docs/images/current_2.png)
Text after The code-under-test has begun running on our computer. We must wait for it to either complete, or make a call that will come to us becuse of our dependency injection.
For the sake of example, let's assume a call comes to us. Because our computer is tied up with the call, it is not free to continue executing. Instead, it must handle the mock call in a specific place, separate from where it called the code-under-test. Therefore, it must use variables to keep track of how far through the test it is. This is why a checklist is used: we keep track by "ticking off" items on the checklist as we receive the corresponding calls.
![I received a call on the injected dependency. Thinks: I can't just let my test case continue here. I will use the checklist to find out whether it is correct.](/coroutines/docs/images/current_3.png) ![I received a call on the injected dependency. Thinks: I can't just let my test case continue here. I will use the checklist to find out whether it is correct.](/coroutines/docs/images/current_3.png)
Text after
It is natural for the checklist to also contain an action to be taken and the required return value for the call. We can insert our own code here, but it is not freely running code: it needs to be put in the place alloted to it.
![The call was correct! Now the checklist tells me how to respond to the call.](/coroutines/docs/images/current_4.png) ![The call was correct! Now the checklist tells me how to respond to the call.](/coroutines/docs/images/current_4.png)
Text after We will assume that the code-under-test now completes after making one call to us. The function call we made earlier on to start the code-under-test now returns, and we can check the return value using free-running code. We are also free to begin another test.
![The code-under-test has completed and I check its output. Test passed!](/coroutines/docs/images/current_5.png) ![The code-under-test has completed and I check its output. Test passed!](/coroutines/docs/images/current_5.png)
### Alternative method
## The same test, using two computers ## The same test, using two computers
![I say "please start the code-under-test". I start the code and inject dependency back to me.](/coroutines/docs/images/cotest_1.png) ![I say "please start the code-under-test". I start the code and inject dependency back to me.](/coroutines/docs/images/cotest_1.png)
Text after Text after
@ -21,7 +28,6 @@ Text after
![I say "the code-under-test has completed and here is its output". I check the output. Test passed!](/coroutines/docs/images/cotest_4.png) ![I say "the code-under-test has completed and here is its output". I check the output. Test passed!](/coroutines/docs/images/cotest_4.png)
Text after Text after
## How do we get to coroutines ## How do we get to coroutines
## Footnote text
The machine shown is a PDP-11/35 minicomputer system which does in fact support timesharing. You would not need two of them to run cotest!
[^1]: The machine shown is a PDP-11/35 minicomputer system which does in fact support timesharing. You would not need two of them to run cotest!