On Wed, 2014-11-12 at 13:32 -0500, Chris Lumens wrote:
Here's a test of the reclaim dialog when it should succeed due to
having
plenty of reclaimable space. That part's easy. The real work here is
making sure multiple tests run in parallel so when we start having a lot
of GUI tests, they don't take all day to run.
You may notice I am being lame and using parted+mkfs to create the filesystem
I then try to reclaim later. I should probably be using blivet directly to
do this. Patches welcome.
I don't think there's any benefit in
constructing a DeviceTree and then
making changes in it for something simple like that. Maybe in the future
when there are 'part' and 'fs' libblockdev's plugins (not a high
priority now, though) we could use it here.
Also note that I am giving each VM 2 GB of memory so there's always going to be
a limit on the number of VMs that can be run. I can perhaps not hardcode the
number of processes and instead figure it out based on the amount of free
memory. I can hopefully also get us more memory for our test systems.
What about
using less memory to also test everything (including zram)
works even with less RAM? From my experience the installation with less
RAM doesn't take significantly more time.
So, where should I be going next?
Do we have a test for the Progress hub behaving
properly when spokes are
not completed, the "Finish configuration" button appears but
insensitive, then they are completed and the "Finish configuration"
button can/should be clicked? I've never seen it broken, but I'm not
sure how much it is tested because people usually enter rootpw or user
information during package installation.
--
Vratislav Podzimek
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic