SCons / scons / 521

75%

master: 80%

Pull #3211

travis-ci

Fix #3156: Modify Dictionary implementation to match docs

Documentation for Dictionary(): "Returns a dictionary object containing
copies of all of the construction variables in the environment. If
there are any variable names specified, only the specified construction
variables are returned in the dictionary." However, in the existing
implementation, if called with no arguments it directly returns the
internal dictionary of the construction environment, the one it uses
to implement its dictionary-like behavior (matches docs); if a single
key argument is passed it returns the value for that key; if multiple
keys are passed it returns a list of the matching values. In neither
of the latter two case does it return a dict object.  This change in
Environment.py aligns the behavior with the docs.

Since all the tests are coded to the actual behavior, rather than
the documented behavior, none demonstrated any problem, which is
only seen if a user themselves uses Dictionary() as documented.
All the tests which depend on the old behavior thus needed some
adjustment. The normal pattern follows this example:

  env['FOO'] = 'foo'
  assert env.Dictionary('FOO') == 'foo'

which breaks when Dictionary returns a dict instead of value. That
can change to either of two following forms - the former is more
like the origial intent, but the second pattern has been chosen
because it looks less awkward, except for a few cases that seemed
to be testing specifically the limiting of the returned Dictionary
by giving it a specific number of keys:

  assert env.Dictionary('FOO')['FOO'] == "foo"
  assert env.Dictionary()['FOO'] == "foo"

A couple of internal tests define dummy classes which implement their
own version of Dictionary.  These needed updating as well.  If the
dummy took no args, it was left alone (BuilderTests.py,  FSTests.py,
NodeTests.py). If the dummy ignored args it still does so, but got a
comment line to that effect.  If it takes one key argument it builds a
... (continued)

4 of 4 new or added lines in 1 file covered. (100.0%)

17434 of 23229 relevant lines covered (75.05%)

3.55 hits per line