CddBranch

Revision as of 11:12, 27 January 2008 by Aleitner (Talk | contribs)


Summary

Video still.png

Play Video!

The Contract Driven Development (CDD) Extension to EiffelStudio. CDD provides full unit test integration into EiffelStudio. Here are some of its features:

  • Automated extraction of test cases from failures
    • For every exception thrown a new test case is created
  • Visualization of test cases and their outcomes
  • One button creation of manual test cases
  • Automated execution of test cases in the background
  • Limit visible test cases via predefined filters and custom tags
  • Testing occurs in the background and is completely undisruptive for the developer


If you have questions, feedback, or would like to report a bug please visit the [CDD forum]

Documentation

Old Documentation

Documentation for the CDD for EiffelStudio 5.7 is available from CddOldDocumentation

Testing

Development (Todo's):

Schedule

  • 04.01.2008: Final experiment definition (questions to ask, how to conduct experiment)
  • 08.01.2008: Finalized list of features to go in release (including logging and log submission)
  • 27.01.2008: Beta 1 (feature complete version online)
  • 04.02.2008: Beta 2 (designated testers test release, # > 3)
  • 11.02.2008: Beta tester feedback in
  • 18.02.2008: Final CDD release for experiment online
  • 19.02.2008: Initial Questionnaire
  • 25.03.2008: Midterm Questionnaire
  • 19.05.2008: Final Questionnaire
  • 20.05.2008: Having all data
  • 06.06.2008: Finished analysis

Stefans Master Plan

  • MA Start ca 17.12.2007
  • MA End ca 17.6.2008
  • Testing the tester
    • System level test for CDD (incl. framework)
    • Recreating existing unit test suite with CDD
    • Large scale validation of CDD
      • Info 4 and/or Software Engineering
      • Questions
        • Does testing (manual/extracted) increase developer productivity?
        • How many tests do ppl end up with (manual/extracted)?
        • ...


Specifications

Things we need from estudio

  • Invariants should be checked during debugging equally to pre- and post conditions (they could also be visualised in the flat view the same way like pre- and post conditions are)
  • The information whether some call is a creation call or a normal routine call (Not sure if this is really necessary, what if we assume every call to some creation procedure is always a creation call?)
  • Support for multiple open targets