So here's a brief summary of how my work to add testing for 5 existing lines of code in rcstpl() led me down a big rabbit hole...
First off, I realized we already had an encoded message in our OUT_3 test file that we could use for this. The lines of code I wanted to test in rcstpl() were for reading a bitmap from an uncompressed BUFR data subset, so conceivably all I had to do was just add that encoded message to one of our existing debufr test cases so that it got read back in, and that would do the trick.
But that's when things got a bit hairy, because as I was looking at the resulting debufr output, I realized that we had an encoding mistake in the original OUT_3 file. Specifically, I had encoded the bitmap backwards, because the bits in a bitmap are supposed to be 0 for a present value and 1 for a not-present (missing) value, whereas I had it the other way around when I originally wrote the outtest3.F90 code. This encoding error didn't affect the ability to read/decode the message, but it was still basically a case of "garbage in, garbage out" in that regard so I wanted to fix it, because that's basically how I roll :-)
And that's when things got even hairier, because I realized that any such change to the outtest3.F90 code and corresponding OUT_3 test file would in turn necessitate moving to a new version number of the emcrzdm tarfile. Otherwise, if we just made these updates to a new iteration of the existing bufr-11.6.0.tgz, then going forward anyone who tried to download one of our older releases from the website would be using the previous outtest3.F90 code and comparing its output to the newer OUT_3 test file, and ctest would therefore fail.
So at this point, and knowing that the next planned release will be v12.1.0 (likely sometime during the next couple of months), I went ahead and generated a new bufr-12.1.0.tgz tarfile to be used going forward for all future PRs. Basically, I updated the VERSION and test/CMakeLists.txt files to start pulling this new tarfile, and which in turn means that the VERSION file is already set for whenever we actually do the next release.
But then I remembered that we had an existing issue #513 that was waiting for just this sort of move to a new version number of the emcrzdm tarfile, since implementing that change would in turn impact a number of additional files inside the existing tarfile, including all of the test output files for all of the debufr cases. So I went ahead and included the solution for that as well.
So here's a brief summary of how my work to add testing for 5 existing lines of code in rcstpl() led me down a big rabbit hole...
First off, I realized we already had an encoded message in our OUT_3 test file that we could use for this. The lines of code I wanted to test in rcstpl() were for reading a bitmap from an uncompressed BUFR data subset, so conceivably all I had to do was just add that encoded message to one of our existing debufr test cases so that it got read back in, and that would do the trick.
But that's when things got a bit hairy, because as I was looking at the resulting debufr output, I realized that we had an encoding mistake in the original OUT_3 file. Specifically, I had encoded the bitmap backwards, because the bits in a bitmap are supposed to be 0 for a present value and 1 for a not-present (missing) value, whereas I had it the other way around when I originally wrote the outtest3.F90 code. This encoding error didn't affect the ability to read/decode the message, but it was still basically a case of "garbage in, garbage out" in that regard so I wanted to fix it, because that's basically how I roll :-)
And that's when things got even hairier, because I realized that any such change to the outtest3.F90 code and corresponding OUT_3 test file would in turn necessitate moving to a new version number of the emcrzdm tarfile. Otherwise, if we just made these updates to a new iteration of the existing bufr-11.6.0.tgz, then going forward anyone who tried to download one of our older releases from the website would be using the previous outtest3.F90 code and comparing its output to the newer OUT_3 test file, and ctest would therefore fail.
So at this point, and knowing that the next planned release will be v12.1.0 (likely sometime during the next couple of months), I went ahead and generated a new bufr-12.1.0.tgz tarfile to be used going forward for all future PRs. Basically, I updated the VERSION and test/CMakeLists.txt files to start pulling this new tarfile, and which in turn means that the VERSION file is already set for whenever we actually do the next release.
But then I remembered that we had an existing issue #513 that was waiting for just this sort of move to a new version number of the emcrzdm tarfile, since implementing that change would in turn impact a number of additional files inside the existing tarfile, including all of the test output files for all of the debufr cases. So I went ahead and included the solution for that as well.
Fixes #513
Hopefully that all makes sense - thanks! :-)