Re: [jamboost] Test system

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-03 20:26:57

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

> Striken. Now the docs have no introduction phrase at all.

Thanks! Are the updated docs still at:

http://chronos.cs.msu.su/~ghost/projects/boost-build/test.zip?

I guess not - when I look there I see the same docs.

>
> I've changed this to BoostBuild.Tester. Hope nobody will mistake
"BoostBuild"
> python module for the actual build system.

We can always change it again...

> > Cool! You might want to model some of the architecture on
Boost.Test. It
> > has
> > ways to specify that particular tests are critical (i.e. should halt
> > the test on failure) or not.
>
> I'm not sure. I still belive that using QMTest will be reasonable. If
we use
> it, it will be possible to specify "prerequisite tests" for any given
tests.

Fabulous. It's already in Python so you can re-use it.

> > > copy_tree -- sets the working tree from existing directory
> >
> > The name copy_tree and the description seem contradictory. The
> > description makes it sound like the working directory is simply
> > changed to be the same as the directory specified (no copying).
>
> The new wording and method name is:
> set_tree -- sets the content of the working directory to be equal to
the
> content of the specified directory.

I'm sorry, it seems worse that way to me. Let me suggest something. Tell
me if this doesn't reflect your intended meaning:

copy_tree - copies an existing directory tree and sets the working
directory to the root of the copy.

> > > TestCmd.write -- sets the content of file in a working
directory
> >
> > Isn't this the same as TestBoostBuild.write? If so, can't we drop
the
> > TestCmd. qualification?
>
> Wanted to emphasize that the method comes from TestCmd, but looks like
it
> will only confuse users, especially since we don't have any docs to
TestCmd,
> except for comments in code.

Agreed.

> > > Examining the working directory and changing it
> > >
> > > The method read, inherited from the TestCmd class, can be used to
> > > read any file in the working directory and check its
> > > content. TestBoostBuild adds another method for tracking
> > > changes. Whenever build system is run (via run_build_system), the
> > > state of working dir before and after running is recorded.
> >
> > Just the working directory, or the whole directory tree?
>
> Does "the state of working directory (and all its subdirectories)"
makes more
> sense?

Yes.

> > > In addition, difference between the two states -- i.e. lists of
> > > files that were added, removed, modified or touched -- is stored
in
> > > two member variables, tree_difference and unexpected_difference.
The
> > > meaning of latter is to contain differences that are not yet
> > > accounted for.
> >
> > What does "accounted for" mean?
>
> Hopefully clarified.

Where?

> > > Writer of tests then removes from
> > > unexpected_difference elements which are OK, for example, if file
> > > foo was added, a call to expect_addition("foo") will remove that
> > > file from the list of unexpected additions.
> >
> > Oh, I think I see, after many re-readings. I think you described
this
> > in the wrong order. I think you should say,
> >
> > "...and after running is recorded.
> >
> > The test writer then calls methods such as
expect_addition("foo.o")
> > to denote expected changes in the tree. When all expected changes
> > have been registered, the "unexpected_difference" attribute will
> > contain a list of all changes not yet accounted for."
>
> Does the new version make it more clear?

I don't know; where is it?

>
> > > Method copy_tree(self, tree_location)
> > > Effects:
> > >
> > > Replaces the current working dir with content of directory at
> > > tree_location. If tree_location is not absolute pathname, it will
be
> > > treated as relative to self.original_workdir.
> >
> > So this does, essentially, "rm -rf * ; cp -r tree_location ." ?
> >
> > If so, you should say, "ERASES the contents of the current working
> > directory and copies the contents of 'tree_location' there", just to
> > be clear how dangerous it is.
>
> Isn't "replaces" quite explicit already?

Explicit, but quiet. If you do say "replaces", please say "replaces the
contents of..."

> > >
> > > Example:
> > >
> > > mul("/home/ghost", [".bashrc", ".bash_profile"])
> > > will return
> > > ["/home/ghost/.bashrc", "/home/ghost/.bash_profile"]
> >
> > IMO it would be better to provide class BoostBuildTest.List, such
that:
> >
> > List(r"this is\ a test") * List(r'.foo .py')
> > == List(r"this.foo this.py is\ a.foo is\ a.py test.foo test.py")
> >
> > List(r'this is\ a test')[1] == 'is a'
>
> Why would you like it? When specifying name to {except, ignore}*
methods, it
> make no difference. Or do you have wider applications for such class?

1. I think it would be cleaner.
2. Fewer quotes
3. I think Scons will want it eventually
4. I am looking into the future at making Scons and Jam more similar.

> I also would like to thank you for all the suggestions you've made
above.
> They really help.

You're welcome.

-Dave