harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stepan Mishura <stepan.mish...@gmail.com>
Subject Re: [testing] code for exotic configurations
Date Mon, 30 Jan 2006 13:03:30 GMT
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("raeburn@ATHENA.MIT.EDU", 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'.

Stepan Mishura
Intel Middleware Products Division

On 1/26/06, Mikhail Loenko <mloenko@gmail.com> 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

Stepan Mishura
Intel Middleware Products Division

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message