Set up test framework

Bastian Doetsch:

I’d like to see a main focus on HgClient? test support. ie, either creating stubs for IProject/IFolder/IFile or use some Mock library.

While their interfaces clearly state they should not be implemented by clients, it can be helpful not having to run tests as “eclipse plugin tests” as these take longer to run.

Maybe create a zip file which contains a repository of a known state which the tests could operate on.

Also, I find that sometimes creating a subclass of a “driver” test-case can help. Ie, the super class contaisn the main setUp/tearDown which deletes the temporary folder and unzips the repository. This mainly works very well when there are assumptions upon implementors of an interface (as it can test that these hold true, independent on the interface), we may not have that yet.

Bastian Doetsch:

Yep, I noticed that it’s quite hard to get this running – especially the Eclipse infrastructure with IProjects, IResources and so on. Perhaps we could use some subclipse stuff as base?

Using a base class for the test cases that does setUp() and tearDown() is the same solution, I’d prefer.

By chyssler on Jul 05, 2008 @ 03:32PM *

I’ve done some refactoring which eliminates some of the obstacles for running the clients in standalone mode. (ie, abstracting away the console, error reporting and default username, timeouts). The second thing is to remove as much dependencies on IResource/IFile/IProject interfaces.

I’ve not pushed this as I’ve not tested it yet, but as a proof-of-concept it works.

The solution is simple, there is a HgClients? class which is configuration and introduces indirection. Ie, yo u initialize he HgClients? with a IConsole, IErrorHandler and IConfiguration instance. This is done by a) the activator of the plugin, which sets up them to function as previosuly b) the setUp of the test-case which sets the console to System.out, error handler to assert.fail() etc..

I’ve successfully ran the status client using this scheme.

What do you think?

To solve the second problem (dependencies on IFiles) we can use them for convenience but always convert and accepts java.io.File instances instead. (and return such). Then provide utilitiy methods for parts which requires the result in IResource format

By bastiand on Jul 05, 2008 @ 10:35PM

This sounds good for testing core resp. the Mercurial layer. For testing other stuff like synchronization, decoration and other thinks that are hard to get right, we’d probably need Eclipse platform tests nonetheless.

But if this enables us, to do more automated testing, I’d definitely like to have such facilities in.

Why don’t you push your stuff as soon as you feel sure that it doesn’t break anything. Unfortunately, I’ve just pushed a new console implementation, so I hope I didn’t create merge conflicts for you.

By chyssler on Jul 06, 2008 @ 10:49AM

I’ve now merged and made some changes, should I push? I need like you to review it since I did some changes

By bastiand on Jul 06, 2008 @ 10:55AM

Why don’t you push it to freehg first – I could pull it from there.

By chyssler on Jul 06, 2008 @ 12:36PM

pushed to http://freehg.org/u/StefanC/mercurialeclipse/

By bastiand on Jul 13, 2008 @ 09:55AM

• → milestone changed from Release 1.0.x to Release 1.1

By bastiand on Jul 13, 2008 @ 10:00AM

• → milestone changed from Release 1.1 to -none-

Updating tickets (#192, #215, #224, #196)

By bastiand on Jul 13, 2008 @ 10:03AM

• → milestone set to Release 1.1

Updating tickets (#192, #215, #224, #196)

in r802 there is now an AbstractCommmandTest? which creates an empty repository for each testcase to operate on.

It does this by unzipping a bundled empty repository to java.io.tmpdir + "test/repo"