Refactor tests to ease implementation #11

Closed
opened 2020-11-29 15:29:22 +00:00 by southerntofu · 1 comment
Owner

Tests have been somewhat disorganized so far. To make it easier to make a new implementation, we should have tests that guide us to write an implementation, i.e. start with "easy" stuff and add new features/constraints as we go.

Maybe something in three phases like:

  1. Output (dummy output, variable context, actual translations)
  2. DVCS backends (sourceless, git, mercurial.. with submodules support where it applies)
  3. Other (host config, environment variables for tasks, logging policy, permission issues)

By proposing to implement output first, we can leverage it later for other tests.

Tests have been somewhat disorganized so far. To make it easier to make a new implementation, we should have tests that guide us to write an implementation, i.e. start with "easy" stuff and add new features/constraints as we go. Maybe something in three phases like: 1. Output (dummy output, variable context, actual translations) 2. DVCS backends (sourceless, git, mercurial.. with submodules support where it applies) 3. Other (host config, environment variables for tasks, logging policy, permission issues) By proposing to implement output first, we can leverage it later for other tests.
Author
Owner

This is done. Tests now are now:

  • basics: CLI flags, log level, log context
  • sources: sourceless, git, mercurial
  • advanced features: host config, task ENV
This is done. Tests now are now: - basics: CLI flags, log level, log context - sources: sourceless, git, mercurial - advanced features: host config, task ENV
Sign in to join this conversation.
No Label
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: forge/build#11
No description provided.