I'd like to add two my kopeks :-) Example, KerberosKey class depends on DES-based encryption to generate a DES key from a user's password. A test may looks like the following:
// Test data from RFC 3961 (http://www.ietf.org/rfc/rfc3961.txt) public void testGetEncoded() { byte[] expected = new byte[] { (byte) 0xcb, (byte) 0xc2, (byte) 0x2f, (byte) 0xae, (byte) 0x23, (byte) 0x52, (byte) 0x98, (byte) 0xe3 }; KerberosPrincipal kp = new KerberosPrincipal("[EMAIL PROTECTED]", 1); KerberosKey key = new KerberosKey(kp, "password". toCharArray(), "DES"); assertTrue(Arrays.equals(expected, key.getEncoded())); } To run the test above the test's configuration has to include a provider that provides required encryption type. I'm not comfort with mocking provider implementation because this complicates tests development: I need to write additional code for each similar case (that is not a couple of lines) instead of using free provider or harmony provider (if we'll have one) for testing purposes. I wouldn't call this test 'a system test': it doesn't verify an underlying system and a provider implementation. It just checks that KerberosKey class has correct implementation. Also it doesn't look like as was written early "quite complicated and can hardly perform the required environment settings (tools installation, platform configuration, etc) from JUnit test." Even more I won't use KerberosKey(KerberosPrincipal,char[], String) constructor in any other testing scenarios. Otherwise I have to put it in a 'system test suite'. Thanks, Stepan Mishura Intel Middleware Products Division On 1/26/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > Well let's start a new thread as this is more general problem. > > So if we have some code designed for some exotic configurations > and we have tests that verify that exotic code. > > The test when run in usual configuration (not exotic one) should > report something that would not scare people. But if one > wants to test that specific exotic configuration that he should be > able to easily verify that he successfully made required conf and > the test worked well. > > The following options I see here: > 1) introduce a new test status (like skipped) to mark those tests that > did not actually run > 2) agree on exact wording that the skipped tests would print to allow > grep logs later > 3) introduce tests-indicators that would fail when current > configuration disallow > running certain tests > > Please let me know what you think > > Thanks, > Mikhail Loenko > Intel Middleware Products Division > -- Thanks, Stepan Mishura Intel Middleware Products Division
