• New Feature
  • Status: Resolved
  • 2 Major
  • Resolution: Won't Fix
  • Build & Test
  • interfaces
  • Reporter: amiller
  • March 05, 2009
  • 0
  • Watchers: 2
  • February 12, 2014
  • February 12, 2014

Description

Currently, writing a system for a TIM or external app is fairly complicated. One issue that impedes the ability to test is the setup of config, which is currently done programmatically through StandardDSOClientConfigHelper. This class a) should not really be public except maybe to tim developers and b) has all sorts of weird methods that are inscrutable for someone not well versed in the guts of tc code.

Ideally writing a system test should require: 1) Providing the tc config, either as a tc-config file (probably minus server/client sections) or through some very basic API. 2) Providing one (or possibly one per node) classes to be run on each simulated node. One common pattern is to use a CyclicBarrier to pick node ids based on arrival times - we could provide this as an input to each node somehow so that’s already done.

Simplifying this api is good both for users and for reducing the api we must expose.

Comments

Tim Eck 2009-03-05

Is this meant to be a replacement for what the “tc:test” goal attempts to provide right now?

Alex Miller 2009-03-05

I’d say no. IMHO, tc:test has issues as a concept as it can only source a single config per test run. I think we should kill tc:test. This would be a simpler way to write system tests with our testing framework, useful not just to customers but to us internally as well.

Hung Huynh 2014-02-12

DSO is discontinued