Okay, this is still a lot of acceptance tests to stack up before any implementation, so I'm going to push through this first one just so we're not crossing objects. Then the rest should be okay in a single commit.

• This should be a Scenario: not a Scenario Outline:, because there's only one case ...
• The title should be 'Get tab stops'. object is implied in the title for all these and just adds noise to spell it out.
• the given is "Given a paragraph format", period. All paragraph format objects have a TabStops object, whether or not it contains any tab stops. And, we always start with the parent object as the given, not further up the hierarchy.
• the then clause is "Then paragraph_format.tab_stops is a TabStops object". CT_TabStops is part of the oxml/xmlchemy layer, not an API object.
• the examples go away because it's a scenario rather than a scenario outline

Okay, this acceptance test is merged in feature/tabstops on the main repo. You should rebase onto that and you can proceed with the implementation of this bit. You can submit all those commits (there might only be one), I expect it will be close enough for me to merge with any tweaks.

I'll provide feedback on the rest now, and you can submit them in commits following the ParagraphFormat.tab_stops commit(s).

In features/txt-parfmt-props.feature
#261 (comment):

@@ -4,6 +4,17 @@ Feature: Get or set paragraph formatting properties
I need a ParagraphFormat object with read/write formatting properties

• @wip
• Scenario Outline: Get tab stops object
• Given a paragraph having tab_stop elements

• Then paragraph_format.tab_stops is a CT_TabStops object
  
• Examples: values for paragraph_format.tab_stop elements

•  | value |
  

•  | no    |
  

•  | some  |
  

Okay, this acceptance test is merged in feature/tabstops on the main
repo. You should rebase onto that and you can proceed with the
implementation of this bit. You can submit all those commits (there
might only be one), I expect it will be close enough for me to merge
with any tweaks.

I'll provide feedback on the rest now, and you can submit them in
commits following the ParagraphFormat.tab_stops commit(s).

Hi Steve,

I'm back from vacation and ready to dive in, but I'm confused by what
you mean here by "the implementation of this bit."

I thought the process was to get a fairly comprehensive set of
acceptance tests in place, then do a series of unit test -
implementation pairings. Am I supposed to do acceptance test - unit
test - implementation of each step as we go? If not, I'm not clear what
is needed under "implementation" for this first acceptance test. It
looks like it fails at the right spot pre-implementation to me, so I
must be missing something.

David

David K. Woods, Ph.D.
Researcher, Lead Transana Developer
Wisconsin Center for Education Research
University of Wisconsin, Madison
http://www.transana.org

Hi David, what I meant by "the implementation of this bit" was the unit-test/implementation pairing(s) that when complete allow the acceptance test I merged to pass.

Then the rest of these acceptance tests can probably come as a group; I'm assuming it compresses to four or so rather than the original nine.

It's a judgement call how many acceptance tests ahead you develop. There's certainly nothing wrong with doing them onesy-twosy at a time with implementation in-between. The problem with stacking up too many is you're getting ahead of your understanding of the implementation and raising the risk you need to go back and change something based on what you learn.

But in this case, four or so is okay, once the actual access of a TabStops object from ParagraphFormat is separated out. These would all be tests of the collection behaviors of TabStops, so it's a coherent set.

Let me know if you need more.