GUI test runner tool

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

GUI test runner tool

Michael Foord-3
Hello all,

Now that unittest has test discovery, Mark Roddy has been working on
resurrecting the old GUI test runner (using Tkinter):

https://bitbucket.org/markroddy/unittestgui

This was part of the original pyunit project but I believe it was never
part of the standard library:

http://sourceforge.net/projects/pyunit/

Here's a screenshot of what it looks like:

http://skitch.com/fuzzyman/dhu9r/pyunit

I'd like to propose adding it to Python in Tools/ and am volunteering to
maintain it. If the answer is "not yet" that is fine as it can go into
unittest2 first. Mark has updated it to work with test discovery and
added support for configuring test discovery in the same way as you can
from the command line. It is a nice tool for those new to writing tests
who aren't yet familiar with the command line or prefer a GUI.

In its basic form you simply pick a directory and unittestgui will
discover and run all the tests it finds. It would be nice if it provided
more diagnostic information on tests it ran (clicking through test
results) but these can be added later.

All the best,

Michael Foord

--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: GUI test runner tool

Brett Cannon-2
On Mon, Nov 8, 2010 at 04:09, Michael Foord <[hidden email]> wrote:

> Hello all,
>
> Now that unittest has test discovery, Mark Roddy has been working on
> resurrecting the old GUI test runner (using Tkinter):
>
> https://bitbucket.org/markroddy/unittestgui
>
> This was part of the original pyunit project but I believe it was never part
> of the standard library:
>
> http://sourceforge.net/projects/pyunit/
>
> Here's a screenshot of what it looks like:
>
> http://skitch.com/fuzzyman/dhu9r/pyunit
>
> I'd like to propose adding it to Python in Tools/ and am volunteering to
> maintain it.

Does that mean upgrading it as well? =) For instance it would be great
to get it to use ttk so it looks a bit sharper, supports skipped tests
and expected failures, and dream-of-dreams ties into regrtest so you
can just check boxes instead of passing a ton of CLI flags.

> If the answer is "not yet" that is fine as it can go into
> unittest2 first. Mark has updated it to work with test discovery and added
> support for configuring test discovery in the same way as you can from the
> command line. It is a nice tool for those new to writing tests who aren't
> yet familiar with the command line or prefer a GUI.

I personally have no problem with it going into tools as long as it
can also be used to run the tests in the stdlib. Just don't put it in
Demos/ . =)

-Brett

>
> In its basic form you simply pick a directory and unittestgui will discover
> and run all the tests it finds. It would be nice if it provided more
> diagnostic information on tests it ran (clicking through test results) but
> these can be added later.
>
> All the best,
>
> Michael Foord
>
> --
>
> http://www.voidspace.org.uk/
>
> READ CAREFULLY. By accepting and reading this email you agree,
> on behalf of your employer, to release me from all obligations
> and waivers arising from any and all NON-NEGOTIATED agreements,
> licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
> confidentiality, non-disclosure, non-compete and acceptable use
> policies (”BOGUS AGREEMENTS”) that I have entered into with your
> employer, its partners, licensors, agents and assigns, in
> perpetuity, without prejudice to my ongoing rights and privileges.
> You further represent that you have the authority to release me
> from any BOGUS AGREEMENTS on behalf of your employer.
>
> _______________________________________________
> Python-Dev mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: GUI test runner tool

Alexander Belopolsky
In reply to this post by Michael Foord-3
On Mon, Nov 8, 2010 at 7:09 AM, Michael Foord <[hidden email]> wrote:
..
> I'd like to propose adding [unittestgui] to Python in Tools/ and am volunteering to
> maintain it.

Why not adding it under Lib/unittest/?   I think Tools/  is a less
attractive location for most users than say PyPI or some other package
repository.  Tools/ is for stuff that is primarily of interest to
python developers, not python users.  OS vendors are less likely to
install packages in Tools/ in a user-visible place than they are a
popular 3rd-party package.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: GUI test runner tool

Raymond Hettinger-4

On Nov 8, 2010, at 11:28 AM, Alexander Belopolsky wrote:

> On Mon, Nov 8, 2010 at 7:09 AM, Michael Foord <[hidden email]> wrote:
> ..
>> I'd like to propose adding [unittestgui] to Python in Tools/ and am volunteering to
>> maintain it.
>
> Why not adding it under Lib/unittest/?  

Michael's instinct to put it in Tools is good one.
GUI preferences and support varies among users and environments.
Also, any given GUI runner is just one of many possible solutions
and there is no reason to commit to one.  Better to add something
to Tools, post an ASPN recipe, or list a package on PyPI.

If you need it to be more visible, we can always give it a mention
in the docs.  Though we might want to mention more full featured
tools like Hudson.

Remember, the standard library is where code goes to die ;-)


Raymond


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: GUI test runner tool

Michael Foord-5
In reply to this post by Brett Cannon-2
On 08/11/2010 19:00, Brett Cannon wrote:

> On Mon, Nov 8, 2010 at 04:09, Michael Foord<[hidden email]>  wrote:
>> Hello all,
>>
>> Now that unittest has test discovery, Mark Roddy has been working on
>> resurrecting the old GUI test runner (using Tkinter):
>>
>> https://bitbucket.org/markroddy/unittestgui
>>
>> This was part of the original pyunit project but I believe it was never part
>> of the standard library:
>>
>> http://sourceforge.net/projects/pyunit/
>>
>> Here's a screenshot of what it looks like:
>>
>> http://skitch.com/fuzzyman/dhu9r/pyunit
>>
>> I'd like to propose adding it to Python in Tools/ and am volunteering to
>> maintain it.
> Does that mean upgrading it as well? =)

Yes...

>   For instance it would be great
> to get it to use ttk so it looks a bit sharper,

I've never used Ttk. Patches welcomed...


> supports skipped tests
> and expected failures,

It already does, the screenshot is a bit old. :-)

>   and dream-of-dreams ties into regrtest so you
> can just check boxes instead of passing a ton of CLI flags.
>
That would be great, but regrtest is a bit custom. It's a great idea,
but would need a different UI shell.

>> If the answer is "not yet" that is fine as it can go into
>> unittest2 first. Mark has updated it to work with test discovery and added
>> support for configuring test discovery in the same way as you can from the
>> command line. It is a nice tool for those new to writing tests who aren't
>> yet familiar with the command line or prefer a GUI.
> I personally have no problem with it going into tools as long as it
> can also be used to run the tests in the stdlib.

Unfortunately the stdlib tests largely aren't compatible with test
discovery. There is an open issue about that. Many of the tests depend
on being run with regrtest, and use features that are in many places now
obsolete due to improvements in unittest. No-one has yet done the work
to switch them over. It is 'on my list' though.

All the best,

Michael Foord

>   Just don't put it in
> Demos/ . =)
>
> -Brett
>
>> In its basic form you simply pick a directory and unittestgui will discover
>> and run all the tests it finds. It would be nice if it provided more
>> diagnostic information on tests it ran (clicking through test results) but
>> these can be added later.
>>
>> All the best,
>>
>> Michael Foord
>>
>> --
>>
>> http://www.voidspace.org.uk/
>>
>> READ CAREFULLY. By accepting and reading this email you agree,
>> on behalf of your employer, to release me from all obligations
>> and waivers arising from any and all NON-NEGOTIATED agreements,
>> licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
>> confidentiality, non-disclosure, non-compete and acceptable use
>> policies (”BOGUS AGREEMENTS”) that I have entered into with your
>> employer, its partners, licensors, agents and assigns, in
>> perpetuity, without prejudice to my ongoing rights and privileges.
>> You further represent that you have the authority to release me
>> from any BOGUS AGREEMENTS on behalf of your employer.
>>
>> _______________________________________________
>> Python-Dev mailing list
>> [hidden email]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>>
> _______________________________________________
> Python-Dev mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk


--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: GUI test runner tool

Michael Foord-5
In reply to this post by Alexander Belopolsky
On 08/11/2010 19:28, Alexander Belopolsky wrote:
> On Mon, Nov 8, 2010 at 7:09 AM, Michael Foord<[hidden email]>  wrote:
> ..
>> I'd like to propose adding [unittestgui] to Python in Tools/ and am volunteering to
>> maintain it.
> Why not adding it under Lib/unittest/?
I really don't want to make Tk a dependency for unittest itself. :-)

I also don't want a GUI test runner to in any way be part of the *api*
of unittest...

> I think Tools/  is a less
> attractive location for most users than say PyPI or some other package
> repository.  Tools/ is for stuff that is primarily of interest to
> python developers, not python users.  OS vendors are less likely to
> install packages in Tools/ in a user-visible place than they are a
> popular 3rd-party package.

Well, there's always Demos/. ;-)

I realise that putting it in Tools/ means that distros will probably
have to make a conscious decision to package it. unittest2 will install
it as a script. I don't think the gui runner belongs in Demos/, so
Tools/ is the logical choice for including in core-Python. As Raymond
says we can point to it in the docs. (The gui test runner is merely a
convenience / beginners tool - so pointing to more "production suitable"
tools like Hudson would also be good.)

I was looking to see what else was in Tools/ that was distributed with
Python, but I don't *think* the Mac distribution includes them at all.
(freeze is in the Tools/ directory of the repo and is an 'end user' tool
rather than core-developer tool.) The Mac distribution does put a bunch
of stuff in the Python 'bin' directory, and ideally it would go there.

All the best,

Michael Foord



> _______________________________________________
> Python-Dev mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk


--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com