NumPy and MatPlotLib

In a recent project, I needed a good way to plot the probability distribution of activation times of phone devices.  I had all the data available, but didn't want to have to plug it all into Excel every time I needed to see the data visualized, so I asked the internet what I needed and it told me that it was probably the hist function in MatPlotLib.  A prerequisite for MatPlotLib is NumPy.  After a medium-sized series of dead ends and red herrings, I determined that the easiest way to access MatPlotLib was to use the exe installers on their public websites even though I didn't initially want my users to have to do that to see the plots.  Turns out that if I wanted to compile NumPy (at least) from source and include it in my project, I'd have to deal with compiling it via GCC and G77 (Fortran 77 compiler) and I'd have to match the compiler version I use to compile NumPy to the compiler that was used to compile the version of Python that I'm running...and I knew I wouldn't do that stuff right on the first try.

Long story short, it was really easy once I selected the correct version of NumPy and MatPlotLib I wanted (note that MatPlotLib links you to the wrong NumPy SourceForge page).  I would suggest that most users just do it that way, it's much more difficult to include those packages in the project.  The documentation is really good for MatPlotLib, at least in the hist function.  NumPy has a lot of good stuff in it too, of course, and I like its docs as well.


When it was all done, I plotted some real data from one of our installs.  It looks rough but it's just about all we need and will get some polish on it.

testresources

Have been working on an implementation of testresources , written by Robert Collins, for some time now, gotten it up and running, and now have good output in Jenkins...therefore, it seems about time to throw all that away in favor of a different implementation.

Although testresources appears much discussed in Python testing circles (see here, here and here), the documentation that exists on implementing it is...fairly sparse, to put it politely.  So over the last couple of days, I've waded hip deep into testresources package code.  I've found that the code itself is elegant and smart (I haven't tested the logic behind the various tools used in the implementation- digraph to graph, minimal spanning tree via Kruskals algorithm, etc.- but I do see that Mr. Collins put a great deal of effort into making it smart and powerful).

In summary, using the testresources package is a great way to allow access to expensive resources (in our case, a Selenium instance that fires up Firefox, imports a profile, and authenticates a user into our web interface) over multiple unit test cases in a suite that all require access to those resources.  The package even optimizes- <i>spelling it optimise to emfasise the British origin of the code, I guess</i>- the use of those resources by re-ordering test cases that call for the same resource to run all together so that, in theory, the resources persists only as long as there is a test case that is waiting to use it, then it is torn down via its native clean and tearDown methods (I say, "in theory," because if a test case changes the state of the resource and marks it <i>dirtied</i> the resource is destroyed and re-created- the order isn't smart enough to check and put any test cases that dirty the resource at the end of the queue so that the ones that can run happily one after the other don't get bogged down.)  To summarize, it does allow you to do some things that PyUnit doesn't allow, and it implements them very well.

Unfortunately, it also limits how you can structure your test cases (everything needs to be flat when you optimize it- one test suite consisting of all the test cases).  That means, you can't have nested suites (suites of suites), or sibling suites that contain cases that share resources.
This would work and be optimized with testresources:

<test suite>
     <test case 1>      - uses resource A
     <test case 2>
     <test case 3>      - uses resource A
     <test case 4>      - uses resource A
</test suite>

This doesn't:

<test suites>
     <test suite 1>
          <test case 1>      - uses resource A
          <test case 2>
          <test case 3>      - uses resource A
     </test suite 1>
     <test suite 2>
          <test case 4>      - uses resource A
     </test suite 2>

</test suites> 

So resource A would be created twice (at least), even though  it's essentially the same as the first structure (except that it uses a suite of test suites).

The next step, I think, is to try an implementation using the nose testing package.  More to follow.

Unit Testing

I'm currently working on a project to reorganize the output of our automated Selenium QA test cases to something that has a finer resolution (each functional test case should have its own output, and that output should be helpful/understandable).

There are a few challenges to this.  The continuous integration package that we currently use is Jenkins (until very recently known as Hudson).  Jenkins can read in XML output from test results, but we don't have any idea what standards Jenkins is looking for- can it handle nests of test cases (called a test suite)?  If it can handle test suite structures in XML, do we have any output generating test runners that can deliver that output?

Unfortunately, as is so often the case with open source code, the documentation to go along with these packages is spare to nonexistent (to be fair, Jenkins has a pretty good Wiki that is just missing coverage on the pieces that I care about now).  I may have to resort to emailing/posting a message to the developer Kohsuke (who is really responsive, it seems) to figure out what Jenkins is looking for.

We've been looking at zope.test and zope.testrunner as possible candidates to speed up execution of our test cases (they allow an environment layer to be set and the unit test cases to run within that environment).  Currently, we use python's integrated unittest package to implement test cases and suites and because of the way unittest works, each test case is run on the same level (so suites of suites of test cases all just become a list of test cases that run in the order they were assembled- so Jenkins displays their results that way- all on the same level).  This is non-optimal because we want to assemble suites to organize sets of test cases based on testing a specific function or page completely, and view the output in the corresponding organizational fashion.

Because of the dependency on the intermediate XML output, we've been playing with subunit2pyunit within subunit, and before that collective.xmltestreport as a possible translator- we switched to looking at subunit because of that message.

In addition, I just found out how to use Setup Tools' easy_install which is pretty fun on installs, but absolutely a pain to uninstall- might as well call it difficult_uninstall as a warning to potential future users.  (The advantage of easy_install for Python developers is that it sets PYTHONPATH references to packages, downloads the appropriate version much like apt-get on Linux, and does a lot of the dirty work of integrating it all into one location- helpful PYTHONPATH link.)  Also, just a note zopepackage is not the same as zope.testrunner (in fact, the zope package doesn't include testrunner anymore just test.)