I just got gsstest set up for my thin shim -- I copied build.NetBSD to build.Darwin and tweaked a couple of things, and faked up some values for platform.h under defined(__APPLE__).
Are you doing a full GSS implementation for your SNC adapter or just a thin shim? (Will you be able to make it public?)
Anyway, I first tried invoking it as './gsstest -l /path/to/sncgss.dyld -a <actual principal name>', and got a complaint that actual_mechs from gss_acquire_cred() contains 2 gss_OID elements, 1.3.5.1.5.2.7 (first) and 1.2.840.113554.1.2.2 (krb5, second). My tests aborted early because no security contexts can be established. gss_acquire_cred Acc() == (GSS_S_NO_CRED), gss_display_status() = "No credentials were supplied, or the credentials were unavailable or inaccessible." This seems to be because gsstest needs to be the acceptor as well, so that it can control both sides of the security context exchange; you will need to use the principal name for a keytab that is available on the machine in question (and readable by the user running gsstest). This should not be the actual production SAP principal!
It seems that the acquire_cred shim may need some persuasion. I know that in recent MIT krb5's GSS libraries, credential resolution is delayed, so acquire_cred() need not actually acquire credentials (inquire_cred() should suffice to force resolution). It is possible that the native system Heimdal library is doing something similar. I will hopefully be pushing my work in progress to https://github.com/kaduk/osxsnc soon, I believe it will fall under a BSD license.