[PyKDE] Eric3 First impressions and questions

[Detlev Offenbach]

> >>1. For some reason profile and coverage statistics does not work for
> >>me. They run but don't show any reports. Right click on source file
> >> -> "Show" submenu has "Code coverage" and "Profile data" entries
> >> but they
> >
> >Are there files ending in '.profile' or '.coverage' located in the
> >directory of the file? Did you run them on the script or on the
> > project? Maybe you can send a testfile and step by step instructions
> > on how to reproduce the problem.
>
> Yes, files with .profile, .timing and .coverage got created. Try to
> use attached test.e3p and test.py.
>
> 1. Open test.e3p project
> 2. Open (double click) test.py
> 3. Right click on editor pane, select Show submenu, notice that only
> "Code metrics" is active.
> 4. Run script (RS from toolbar), you'll get typical unittest output
> "Ran 1 test".
> 5. Profile script (PS from toolbar), you'll get "Ran 0 tests" output.
> (this operation creates test.profile and test.timings files)
> 6. Right click on editor pane, select Show submenu, notice that only
> "Code metrics" is active.
> 7. Run coverage report on script (CS from toolbar), you'll get "Ran 1
> test" output. (this operation creates test.coverage file)
> 8. Right click on editor pane, select Show submenu, notice that only
> "Code metrics" is active.
>
> Note: it is likely to be a problem with project file. When script ran
> outside of a project everything works fine.

The problem here was, that you didn't define a main script for the 
project. Nevertheless, there I made a false assumption in the logic of 
the "Show ..." functions, which will be changed in the next snapshot.

>
> While looking into this, I notices another bug (?). Try to create new
> project, select main folder, enter name, enter main script (all
> folders/files selected via file selector, not typed in). Hit Ok. New
> project gets created, but it does not have any files in it. I would
> expect to see script, which I selected as Main script, to be
> automatically added to project.
>

That will be added in the next snapshot and work like this.
If there exists a file with the name given in the Main Script entry, it 
will be added.

> I am using Debian unstable. Python 2.3.3, Eric 3.4.1
>
> >>are inactive. Another weird thing is that when I am trying to
> >> profile my unittest I get "0 tests run" in the report. Tests set up
> >> in usual way
> >>
> >>if __name__=='__main':
> >>    unittest.main()
> >

This will be in the next snapshot.

> >>way to run tests with a single key. BTW, while we are at it, it
> >> would be really nice to make unittest screen a dockable panel
> >> rather than separate window.
> >
> >This was done intentionally because unittest can be started as a
> >standalone application as well, i.e. without starting the eric3 IDE.
>
> I see. Let me try to convince you that one way or another it is really
> important to be able to run tests fast, preferably with a single
> keystroke.
>
> The whole idea of test driven development (extreme programming, agile
> programming, put you favorite test driven methodology here) is "test
> early, test often". Ideally you want to be able to write a single line
> of code and run tests, write another line, run them again. Of course
> development is not always done in such baby steps, but it is important
> to have such an ability. Now in current eric setup hitting keyboard
> shortcut for unittests (or clicking UT icon on toolbar) does not bring
> unit testing window up if it was already open. When you get to that
> window, hitting Enter does not run tests (while enter in run script
> dialog works), so you have to either use mouse to click Start button,
> or hit Alt-S. The best I can do at the moment is to use Alt-Tab (to
> switch to unittests) then Alt-S to run them. That works only if I
> haven't switched to any other windows in meantime (or I have to
> alt-tab more then once), and only if I want to run unit tests on the
> same script as before. But even in this case necessity to switch
> between windows is rather annoying, discouraging me from running tests
> as often as I want to. So my current solution is to use "Restart
> script" for unit testing.
>
> Lets pause for a second and review possible ways to arrange unittests
> in a big project. One way is to put test code into the same file as
> project code. IOW, tests for functionality implemented in file foo.py
> lives in foo.py and ran via classical trick:
>
> if __name__=='__main__':
>     unittest.main()
>
> To support this naive style we need an ability to run unittests on
> current open script with a single key. As a compromise special key to
> bring unittesting dialog and set script to current open script. Or
> maybe rework unittesting dialog a bit to have two options: run current
> script open in eric, or run arbitrary script. This way shortcut may be
> named "run unittests with last used settings". BTW, am I overlooking
> something, or is it really impossible to record macros operating on
> unittest dialog?
>
> Alternatively, one can opt for putting test code in separate files.
> For example testfoo.py will have tests for foo.py. In this setup
> ideally IDE should allow associate test script with every python
> script. This sounds like a lot more work, but it will ultimately solve
> all unittesting problems.
>
> Apart from running unittests on current script, the whole project can
> be tested periodically (before commit to source control for example).
> So another nice addition to unittesting functionality would be to have
> "Unittest script" and "Unittest project". The latter one can be
> implemented either via running the same Main script as all other "*
> project" operation do, or, to allow more flexibility, have a "Main
> testing script".
>

I am planning to extend the unittest like this.

Add two actions in the IDE for "Unittest Script" and "Unittest Project". 
If there is a script called like the current script, but starting with 
test (e.g. foo.py -- testfoo.py), unittest will be called with the test 
script (i.e. testfoo.py). If no such script exists, it will run with the 
current script (i.e. foo.py). Same logic for the project using the main 
script. There will be no separate entry for a "Main Test Script".

There will be a third action, which will rerun the last unittest 
performed.

> Thanks again for such a nice product. Don't be discouraged by my
> unittest ranting -- I really like eric a lot. I am simply trying to
> show what could be done to make it even better.
>

I am glad somebody gives the unittest module a kick and sends feedback in 
order to improve it. Eric should be an IDE, that eases the developer's 
work. In order to achieve this, I need the feedback of developers.

Detlev
-- 
Detlev Offenbach
detlev at die-offenbachs.de