Getting Started
IntroductionGetting startedOverviewRunning TestoTests running policyTesto for Hyper-V Guides
Guide 1. The very first testGuide 2. Ubuntu Server InstallationGuide 3. Internet access in virtual machinesTesto for QEMU Guides
Guide 1. The very first testGuide 2. Ubuntu Server InstallationGuide 3. Guest AdditionsGuide 4. ParamsGuide 5. CachingGuide 6. Internet access in virtual machinesGuide 7. Linking up virtual machinesGuide 8. Flash DrivesGuide 9. MacrosGuide 10. If clauseGuide 11. No snapshotsGuide 12. Mouse controlGuide 13. Importing disk imagesGuide 14. JS-selectorsGuide 15. CyclesGuide 16. Macros with declarationsReference
Test scripts general overviewTesto lang basic syntaxVirtual Machine declarationVirtual flash drive declarationVirtual network declarationParamsTests declarationMacrosVirtual Machines ActionsMouse actionsDetecting images on the screenVirtual Flash Drives ActionsConditionsCyclesPossible keyboard key IDsJavascript selectors
Main conceptsBuilt-in global functionsExceptionsClass TextTensorClass ImgTensorClass PointGuide 13. Importing disk images
What you're going to learn
In this guide you're going to learn how to "import" manually prepared virtual machines into your test scripts.
Preconditions
- Testo Framework is installed.
- Virt manager is installed.
- Ubuntu Desktop 18.04 image is downloaded.
- (Recommended) Testo-lang syntax highlight for Sublime Text 3 is set up.
- (Recommended) Guide 12 is complete.
Introduction
In all our previous guides we've sticked to the concept of deploying the test benches from scratch. The virtual machines we created were absolutely blank: just a bunch of virtualized hardware with nothing installed. We had to automate everything: OS and guest additions installation, the network setups and so on. This approach has some great benefits to it:
- All you need to deploy the test bench is a set of ISO-images and some small additional files you can keep in a VCS. So you can easily move the test bench to a new computer: just download the repository and the iso-images.
- The test scripts are basically a documentation for the deploying process of the test bench: just read the scripts and you'll know what exactly happens to the test bench. From the very beginning!
- You can easily adjust the test bench preparation steps. Just change any actions you want (in any part of the preparation process) and Testo will do the rest to get the test bench into the state you want it to be.
However, the approach has some downsides as well:
- Sometimes the preparations are just too large and tedious to automate, and, therefore, developing the test scripts from scratch is just too long and ineffective.
- Sometimes you want to just focus on the actual tests for the SUT and you don't want to spend your time automating the secondary virtual machines setups. Maybe it would be so much easier for you to just do some manual job preparing your secondary virtual machines and then just import the results into the test scripts.
So the Testo Framework gives you the opportunity to take a different approach for deploying the test becnhes: you may prepare a virtual machine yourself (or just get it somewhere) and then import its disk into a virtual machine in your test scripts. This way you can start the scripts not from scratch, but from the point you see the most preferable. And this is what we're going to learn about in this guide.
What to begin with?
Let's take, for instance, the Ubuntu Desktop 18.04 installation. In the previous guide we've managed to automate the installation for this OS using mostly the mouse. But let's assume, that we don't want to automate the OS installation. That we just want to do it manually one time, then stage our efforts and import the result as the starting point for the ubuntu_desktop
machine.
Well, let's get right to it.
For starters, open virt-manager and create a new virtual machine (we're going to call it handmade
). The configuration may be arbitrary (just don't forget to specify the Ubuntu Desktop iso image), with the exception for the main disk size:
This is the disk we'll later import into the ubuntu_desktop
machine, so let's give it the size of 10 Gigabytes (just like in the previous guide).
When the virtual machine is created, just install the OS manually.
After the virtual machine is installed, let's do a super-quick "setup" for it. To mimick a setup let's create an empty folder Handmade_folder
on the Desktop, so later on we could make sure that we actually imported the handmade
machine successfully.
Now turn off the handmade
machine, since we're ready to import the results into the test scripts.
Importing the handmade
machine disk into the test scripts
Now when the manual setup is finishedб we need to move back to the script developing. Let's create a new .testo
file, name it handmade.testo
and declare a virtual machine ubuntu_desktop
like this:
machine ubuntu_desktop {
cpus: 1
ram: 2Gb
disk main: {
source: "${VM_DISK_POOL_DIR}/handmade.qcow2"
}
nic internet: {
attached_to: "internet"
adapter_type: "e1000"
}
}
test check_handmane_ubuntu {
ubuntu_desktop {
start
wait "Handmade" timeout 3m
}
}
There are two interesting moments in the virtual machine declaration:
- The
main
disk now has thesource
subattribute instead of thesize
subattribute. In thesource
subattribute we need to specify the path to thehandmade.qcow2
disk image. When theubuntu_desktop
is created, this image will be copied and imported into its configuration. The originalhandmade.qcow2
isn't going to be affected in any way. ubuntu_desktop
doesn't have theiso
attribute. Indeed, there is no need for the installation medium now, since the Ubuntu is already installed.
We also developed a very basic chack_handmade_ubuntu
test, in which we're going to make sure that the import is a success. The virtual machine is created in the turned off state (as usual), so first we need to start it. Then we're waiting for the Desktop to appear with the Handmade
folder on it. Once the folder is detected we'll know that everything is OK.
There is no login prompt because we chose "Log in automatically" when installing Ubuntu manually. If you'd chosen "Require my password to log in" - then please adjust the
check_handmade_ubuntu
test accordingly.
Let's run the script (take a look at the VM_DISK_POOL_DIR
param value - this is the default path to the disk images of the virtual machines created with virt-manager).
TESTS TO RUN:
check_handmane_ubuntu
[ 0%] Preparing the environment for test check_handmane_ubuntu
[ 0%] Creating virtual machine ubuntu_desktop
[ 0%] Taking snapshot initial for virtual machine ubuntu_desktop
[ 0%] Running test check_handmane_ubuntu
[ 0%] Starting virtual machine ubuntu_desktop
[ 0%] Waiting Handmade for 3m with interval 1s in virtual machine ubuntu_desktop
[ 0%] Taking snapshot check_handmane_ubuntu for virtual machine ubuntu_desktop
[100%] Test check_handmane_ubuntu PASSED in 0h:1m:13s
PROCESSED TOTAL 1 TESTS IN 0h:1m:13s
UP-TO-DATE: 0
RUN SUCCESSFULLY: 1
FAILED: 0
user$
We can see that the test passed successfully, which means, that the Handmade_folder
was detected after all. The manually-created virtual machine import is complete!
The imported disks caching
Despite the fact that we imported an existing disk image (its copy, to be precise), the virtual machine is still cached with the same caching rules we've learned earlier. The same as before, after the virtual machine is created, the initial
snapshot is taken, and at the end of each successful test a new snapshot is created as well (except for when the test
has the no_snapshots
attribute).
We can make sure that everything is cached if we just run the tests one more time:
UP-TO-DATE TESTS:
check_handmane_ubuntu
PROCESSED TOTAL 1 TESTS IN 0h:0m:0s
UP-TO-DATE: 1
RUN SUCCESSFULLY: 0
FAILED: 0
user$
But what if for some reason we want to change the starting state of the ubuntu_desktop
machine? Let's assume, that aside from the Handmade_folder
on the Desktop, we also want to change the screen resolution from 1024x768 to 800x600. How can this be done?
As a matter of fact, the cache validity rules for imported disk images are exactly the same as for the iso
attribute: if the original disk image file changes, the cache is invalidated for all the tests which involve this virtual machine.
So let's try this out: start the handmade
machine and change the screen resolution:
That's actually all you need to do! Just turn off the handmade
machine now and run the test scripts again:
Because of the cache loss, Testo is scheduled to run the following tests:
- check_handmane_ubuntu
TESTS TO RUN:
check_handmane_ubuntu
[ 0%] Preparing the environment for test check_handmane_ubuntu
[ 0%] Creating virtual machine ubuntu_desktop
[ 0%] Taking snapshot initial for virtual machine ubuntu_desktop
[ 0%] Running test check_handmane_ubuntu
[ 0%] Starting virtual machine ubuntu_desktop
[ 0%] Waiting Handmade for 3m with interval 1s in virtual machine ubuntu_desktop
[ 0%] Taking snapshot check_handmane_ubuntu for virtual machine ubuntu_desktop
[100%] Test check_handmane_ubuntu PASSED in 0h:1m:15s
PROCESSED TOTAL 1 TESTS IN 0h:1m:15s
UP-TO-DATE: 0
RUN SUCCESSFULLY: 1
FAILED: 0
user$
As we can see, the cache is lost and the test is re-run. So basically every change you do in the original "source" virtual machine is instantly reflected in the test scripts.
Conclusions
There are two approaches to virtual bench deploying in Testo Framework: doing everything from scratch and importing existing virtual machines' disks into the test scripts. Importing existing disks may be convenient and useful if you don't want to spend your time automating preparatory tests. "Imported" virtual machines have the same caching rules as regular ones.
You can find the complete test scripts here.