Srecode loads in templates for various modes and applications into a map. That particular test is verifying that the template associated with srecode's template mode for the application 'tests' was found.
There are 2 templates for the 'test' application in:
etc/srecode/proj-test.srt.
etc/srecode/test.srt
Plus the template template:
etc/srecode/template.srt
You can use:
M-x srecode-get-maps RET
to list all the templates discovered during srecode initialization on the different platforms to see what is different.
The first part of the list are the mode specific template files. After are the application templates, and tests app should be in there. (It was first for me when I just tried it.)
What *might* be going on is ~/.emacs.d/srecode-map.el could be out of date for whatever user/machine is running the test. Discovering all the templates is a bit slow, and srecode will rescan files that change but doesn't know what files to scan based on file name, so the map and the cache was meant to speed things up. You can force a reload by passing non-nil into srecode-get-maps. The earlier test srecode-utest-map-reset should do that, but as I look at the code, I don't see that it is. In the old cedet test suite, all the tests were run in a forced order w/out ert (it wasn't around, or I didn't know about it when I was writing tests the first time.) Thus, there may be some order dependency I don't know about.
Hopefully this is helpful. I don't usually have this much time to poke around in emacs anymore. You caught me on a good day. :)
Eric