Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools

The following represents my(==ld) recollection of the proceedings we agreed on, during our meeting Tue, May 4th 2004. Items in italic indicate assumptions and additions i made myself

Please correct, annotate, comment, whatever.


  1. explore how the eclipse folks do their compiler/ast testing.
  2. try to adopt as much of their code/experience to JTransformer2 as possible. In particular:
    1. evaluate their coverage of the JAVA language (compiler tests)
    2. evaluate their test code/examples modularizable? (“We want small, managable Code snippets!”)
    3. can we reuse their Testbed?
      1. proove it by implementing a small example
  3. wait for possible structural changes in the PAST design
  4. use code examples from the eclipse test suits to implement 110% (language-wise) test coverage of the fact generation process (i.e. factgenerator, IDResolver and friends)
  5. adopt our old tests where applicable
    1. in particular tests on detail problems, e.g. String literals, …
    2. GET RID OF (the old) testbed

How and What do we test

  • Tests should be fast, otherwise they will not be run.
    • –>try to disable platform ui! (should be result of the findings above)
  • We do not test implementation but results
  • For a given code snipped, we assume a priory knowledge of the complete and correct output generated by our system, so we can (and should!) do barely more than string comparisson.
  • We test with “everything ON”
    • in particulary, we do not disable slT-facts during testing.
  • we try to establish and maintain comman structures and methods(t.b.c.)
research/jtransformer/trash/howwewritetests.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019