1

Topic: Idea for Automated Testing of GParted

With an application like GParted, reliable operation and protection of data is extremely important.  Some form of testing would be a good step towards ensuring that each GParted release functions properly and reliably.

In an effort to ensure that GParted does perform reliably, I have been manually testing various areas of GParted prior to each release.  This effort is time consuming and hence I am only able to test a small portion of functionality.  I keep thinking there must be a better way.

There are many areas and types of testing.  Fortunately, the parted project already has a test suite to ensure that parted/libparted is functioning properly.  Hence I think we can focus is on the graphical interface, and the operations that use both file systems tools and libparted.  Further, to get the most payback for effort, I think regression testing is the area to focus on.

A list of Open Source GUI testing tools can be found at the following link:
List of GUI testing tools

The most promising one to me appears to be the Linux Desktop Testing Project.

My reasoning is that this project is still seeing active development, and also has packages already built for popular GNU/Linux distributions such as Debian, Ubuntu, and Fedora.  This should make testing on multiple distributions easier.

Does anyone have testing experience, advice, or comments to build on this idea?

2

Re: Idea for Automated Testing of GParted

Yes, I believe LDTP should be a good choice.

3

Re: Idea for Automated Testing of GParted

For the test structure, I was thinking that a modular approach might work well.  My goal is to try to keep the maintenance of the testing code to a minimum.

The structure I was thinking about involves modules as follows:

  • disk device creation modules (using scsi_debug, or a loopback device)

  • GParted startup modules that could be passed the disk device to operate on

  • partition table creation module that could be passed the type of partition table

  • partition / unallocated space selection module

  • partition creation modules that could be passed partition type, size, fs type, etc.

  • partition operation modules defined similarly with parameters passed in

In this way tests could be developed by stringing together a series of modules.

If someone has a better idea, or other comments, then I'd be interested to hear what you have to say.