7.3.1 Back-end Testing: Main Tests
This testing demonstrates the wide range of conversions that are possible with the system. However, it also highlights some drawbacks. The causes of these failures are all either known to us, or we can make a reasoned guess; however perfect solutions to them are not known in all cases. We will now examine the failures, and attempt to explain why they occurred.
It was found that sometimes, test 19 failed because the system substituted pole, as the test case expected, for perch, which is a pseudonym for the same unit.
Test 98, which was converting 10 decimetres cubed into litres, should clearly give 10 as the result. The failure of this test appears to be due to rounding errors, due to the use of finite-precision floating point arithmetic.
Tests 140, 141 and 144 are conversion to measurement standards. However, because the algorithm used only looks in the same graph for units of that standard, it does not work for derived units. There were two reasons for this design decision, and they are explained in the implementation chapter, section 5.8.
Tests 151 and 152 reveal a deficiency in the algorithm for determining the dimension. For compound units, it attempts to find two units divided, a squared unit, then a cubed unit, and finally two units multiplied together. An early version of the system returned the
CHAPTER 7. TESTING 73 unknown dimension error when it managed to find one of the above combinations of units, but the result did not match a dimension known to the system. It was realised that this was very restrictive, and instead if a dimension that was not known to the system (by this we mean that the system did not have a definition for that dimension, for example from the Content Dictionary dimensions1), the dimension would be inferred, the graph created and added to the HashTable. It was realised that these could not be compared by the names; if the system has “invented” a dimension, it will not know the common name for it, so instead the FMPs of the dimensions are compared at this stage. However, this system is not perfect either, because the units end up grouped together differently, so it might get (mass length) per (time sqrd), which is in fact the same as force, but the algorithm cannot detect this, because it has created a new dimension mass×length during the process, and this is not part of its definition of the force dimension. Although, as test 157 shows, it can create a dimension which in fact is the same, and because it has found the same “new” dimension for both source and destination, the conversion works.
Test 167 fails due to a problem with the CreateConversion method, where, because the destination unit is prefixed, when the constituent units are obtained, this only consists of the prefixed version of the unit, and the unit itself; both of which share the dimension of the source unit as a whole. The algorithm has some code to avoid this in many cases (as described in Section 5.3.4); however, it is not successful in the case of bar, because when not prefixed, it is still only in terms of one other unit. Attempts to use the same fix as for other prefixed destination units failed. This will need further investigation.
Tests 174 and 175 also reveal a similar deficiency in the dimension-determining algorithm, in that it cannot tell that Watt×second is in fact Joule, or rather, that power×time is the same as Energy. The algorithm will need rewriting to treat dimensions more algebraically, rather than just joining them together blindly.
Tests 182 and 183 demonstrate the same fault as test 167.
Many of the mass conversions reveal a problem with the system’s prefixing routine, in that “tonne” should not take prefixes. One source seems to state that “kilo-”, “mega-”, and so on, are becoming recognised ((Belgian Ministry of Economic Affairs 1970) refers explicitly to the mass form of tonne, as opposed to the “megatonne of TNT” energy unit), but it seems agreed that tonne still cannot take the prefix “milli”. This was discovered after the test plan was completed.1 Despite this oversight, the tests have proved useful in that they
demonstrate a problem with the system.
Besides the main tests of the back-end, there were also other tests performed on the back- end, and on the front-end also. As can be seen from the time column of the results table, conversion is well within the boundaries specified. In fact, when the local files were deleted, the time taken to download them and return the result for the first test was also under 10 seconds, and subsequent calls to the program used the downloaded files and therefore
1This paper was found through the International Bureau of Weights and Measures, which lends credence
to it. Other sources appear to disagree, and the BIPM source itself does not make an explicit statement either way.
CHAPTER 7. TESTING 74 ran in a comparable time to prior to the deletion. So it turned out that the 10/20 second limit on getting a result back was very high—the result never took more than 4 seconds to be supplied. However, it was noted that the limiting factor tended to be the network connection—when this was removed, and the system had no choice but to use its local files, the results were much more rapid. So even though no downloading was actually done with the network connection (just last modified dates compared), this was a limiting factor.