If I have understood correctly, the objective is to check a dir-tree
to ensure that specific directory/file-permissions are in-effect/have
not been changed. The specifications come from a .JSON file and may
be over-ridden by command-line arguments. Correct?
Yes.
How to test this in the best way?
The best way to prepare for unit-testing is to have 'units' of code
(apologies!).
An effective guide is to break the code into functions and methods,
so that each performs exactly one piece/unit of work - and only the
one. A better guide is that if you cannot name the procedure using
one description and want to add an "and" an "or" or some other
conjunction, perhaps there should be more than one procedure!
For example:
> for cat in cats:
> ...
> for d in scantree(cat.dir):
> # if `keep_fs` was specified then we must
> # make sure the file is on the same device
> if cat.keep_fs and devid != get_devid(d.path):
> continue
>
> cat.check(d)
Above is part of the main() function. But I could make some part of
the main() function into its own function. Then the call to check a
directory could be a function argument. For testing I could reuse that
function by providing a different function for the check (now it is
cat.checkid(d) )
There is no $charge for the number of functions used. Don't hesitate!
Whilst I haven't heard the phrase used recently, we used to talk about
systems- and program-design being a process of "step-wise
decomposition". It was likened to peeling layers off an onion, or
Russian nesting dolls - as one takes 'off' the outer layer, there is
more inside.
In programming then, the main() calls a bunch of other functions. Each
of those, calls its own set of sub-functions, and so-on. At first, we
are talking 'higher levels' of control - and a good choice of function
names summarises what's going-on/provides the 'plan of attack' and thus
good "documentation"!
As control passes to the 'lower level' of functions, the level of detail
increases. You might think of it like a microscope - the more powerful
the magnification, the more detail is seen; but the field of view has
narrowed/become more focussed.
The idea of having one function perform one (and only one) function is
known as "encapsulation". Another term which was a new 'buzz-word',
decades ago, is "modular programming" - instead of having one long
program, splitting it up into functional components.
Yet another traditional phrase describing computer programs is: "input,
process, output". This can also be applied, at the successive levels of
detail, to functions - they 'take in' parameter-values, 'process' them
in some way, and then return, or 'output' the result.
In a simplistic world, one function's output would become input to the
next function. However, back in the real-world, it is more likely that
several 'outputs' from earlier functions are used as 'input' by some
successive procedure. Which is why we are paid 'the big bucks' (maybe).
Earlier functions should only influence or affect the behavior of later
functions by passing data (output from one, becoming input to another).
The complex ways in which functions can 'feed' or 'affect' each other is
called "cohesion". If each function is dependent only upon its input
data, this is held as an ideal. If a function is not independent, that
is likely to be and/or become a source of friction and bugs. Again, in
an ideal world...
There's a lot of follow-through, if you'd care to do some reading using
such key-words...
If this were a function, how would you name it? First of all we are
processing every category, then we are scanning a dir-tree, and
finally we are doing something to each directory found.
If we split these into separate routines, eg (sub-setting the above):
> for d in scantree(cat.dir):
do_something_with_directory( d )
and you devise a (much) more meaningful name than mine, it will
actually help readers (others - but also you!) to understand the
steps within the logic.
Now if we have a function which checks a single fileNM for
'whatever', the code will start something like:
def stat_file( fileNM ):
'''Gather stat information for nominated file.'''
etc
So, we can now write a test-function because we don't need any
"categories", we don't need all the dir-tree, and we don't need to
have performed a scan - all we need is a (valid and previously
inspected) file-path. Thus (using Pytest):
def test_stat_file( ... ):
'''Test file stat.'''
assert stat_file( "...file-path" ) == ...its
known-stat
def test_stat_dir( ... ):
'''Test file stat.'''
assert stat_file( "...dir-path" ) == ...its known-stat
There is no need to test for a non-existent file, if you are the only
user!
In case you hadn't thought about it, make the test path, part of your
test directory - not part of 'the real world'!
...
The comments/advices I got were pretty helpful. I already have
started to make improvements in my code to be able to test things
better.
For example I have changed the check() method in the Policy class to
get called like this:
def check(self, fpath, user, group, mode):
This means I can test the checks and its result without requiring any
external test data.
Thanks a lot to all for your help.
Given your replies, 'now' might be a good time to take a look at Pytest,
and see how you could use it to help build better code - by building
tested units/functions which are assembled into ever-larger tested-units...
(there is a range of choice/other testing aids if Pytest doesn't take
your fancy)
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
