Hi everyone,

I recently started to like the idea of supporting unit tests natively in languages more and more, here are two posts where I give some background on this idea:

• http://beust.com/weblog/archives/000523.html
• http://beust.com/weblog/archives/000524.html

Andy, Brian (and the rest of the community), I would be curious to hear your thoughts about this, and more specifically, if you would consider implementing this in Fan?

Cedric

An interesting read. From what I've seen native test seemed to be (semantically) bound to the class/function they are testing.

So the question asks itself, how would integrations tests be handled? Would it be possible to group different unittest into more complex stuctures.

I think it's important to remain very modest with this functionality for a couple of reasons:

• Not burdening the language with too much extra complexity (both in parsing and readability)
• Integration testing frameworks can be pretty sophisticated (e.g. http://testng.org, just to name one :-)) so they should probably remain external to the language

Hi Cedric,

Currently Fan does have built-in unit testing in terms of:

• sys::Test class
• fant command line tool

We don't have any keywords or special language syntax, but I personally would describe Fan's support for testing as built-in. But I guess it is really how you define built-in.

My thoughts are that tests should be managed in separate source files, which is why we haven't needed a special keyword. But I do think it is important to toggle test code as included or excluded in a given module. Right now I think that would be by convention based on whether it is stored in the "test/" sub-directory. But we might want to formalize with a facet or something in the build script.

So I think that a standardized test harness should be part of a given language's overall platform infrastructure. But I question that testing should require special syntax. Seems like more of a library issue to me. Special syntax only comes into play if you really think that tests should mixed into the same source file as production code (something I don't personally like).

If I understand correctly unittest have the same scope as the class they are in.

This prevents making auxiliary methods that expose some functionality you don't want in production code so tests could access it.

My Software Engineering professor mentioned that often people would write auxiliary code (for example a method that does drop table) so their tests could use it, but then they would forget to delete it, allowing hackers to exploit such undocumented vulnerability to very easily and effectively wreak havoc.

If specified tests could be given access to private or protected fields I think it wouldn't really matter whether you write your test inside your class or in another directory (if I recall correctly one Fan file can contain multiple class files just no inner classes). A simple facet

@TestInject(MyPod::FooTest)
private bar

where class FooTest : Test

would cover most of use cases where unittest has benefits. Unless I'm missing something about them?

I would be happy to see an experiment where tests were written in the same source file as the main class. Since Fan[tom] supports multiple classes in the same file, this isn't a problem. In this case, the test is simply a parallel class in the same file.

Now, you could add syntax like:

class Foo {
  ...
}
unittest Foo {
  ...
}

such that the unit test is an alternate class type like enum that generates the output into a separate directory, but I don't see much difference to facets:

class Foo {
  ...
}
@Test
class TestFoo {
  ...
}

Then again, if we find this style of testing takes off and is successful, the keyword can be added later.

Already today you can put your tests in the same source file:

class Foo {... }
class TestFoo : Test {...}

It is just convention to put your tests in a different directory, but it is not required.

I think the big part of using unittest is so programmers would be forced to put their test where their code is. That way when you get code you get its accompanying tests as well.

Btw most of the unittest-like construction (D, inner classes and Noop language) made looked like this.

class Foo {

  unittest FooTest : Test 
  {
  ...
  }
}