The end of the 2nd Coding Period of this year’s Google Summer of Code has finally arrived. I cannot help but noticed the many things I have learned/built over the past two months for both the glue Graphical User Interface (GUI), as well for its solar physics plugin glue-solar. One of the tricks I have learned is writing up tests for the GUI programming I have done in the process, which is using Qt for Python to port the entire PySide module to Qt5. My main approach is quite simple: Imitate, modify, test. Since glue has a fairly well developed codebase, it is not hard to find sample code snippets within it for inspiration of new code to add. The GUI unit tests are no exception to this rule. And, I would like to use the opportunity to share the experience with more novice contributors to the software, so perhaps somehow someone else somewhere down the line will be able to benefit from this.

The first and foremost concern we should have regarding any type of unit testing is what we should check for functionality-wise. Let me take some code I have just written over the past few days which adds NDData (a data structure native to Astropy) support to glue and enables the loading of various types of astronomical data more readily, such as the standard FITS files. As I have discussed with my mentors via the glue-solar IRC channel, we have observed that NDData is much like laser was back in the 1960’s (e.g. as reported by NYTimes then) was a solution in search of a problem before its wider adoption by the astronomy community for LSST, DKIST and CCDProc data. Now we are in the process of integrating it into glue. The original conception of this, at least in principle, is to use the simple and fluid structure of NDData to help process for example FITS data. This is because there are no generic NDData files in existence at all. This is to facilitate the manipulation of not only the data component, but also its units, mask, uncertainty, and meta attributes, which are quite common in the handling of astronomical data (pun intended). With such a motivation in mind, we have added a nddata.py module to the glue/core/data_factories directory in a PR at glue. To complete the PR, it is standard practice to add tests where applicable, so we have added a testing module called test_nddata.py in the glue/core/data_factories/tests directory to not only serve as a routine, but also to test whether the code has been properly debugged, which caught all of the major known bugs I have inadvertently introduced to the codebase before testing.

The GUI unit test I have written is as follows:

I have studied the other tests in the same glue/core/data_factories/tests carefully before I proceed to write the code, as I have observed that the most basic test to write is to test the data loader. Of course, official docs helped me greatly as well. As for the formatted NDData factory, that would be hard to test. I will need to consult with my mentors, before deciding on whether a separate unit test for that later.

One takeaway I have come away with in the process is that sufficient time is needed before I could brainstorm and come up with a tangible plan to write unit tests for any established codebase, and that I should not rush through the process. This is a lesson that I will definitely keep in mind. There is no use going through the motion and not enjoying the process as I go along, not to mention the omissions that I would make otherwise without a well thought-out plan.