[Fuego] [PATCH] bind: Add test cases for commands of bind(chroot).

[Tim.Bird at sony.com]

> -----Original Message-----
> From: Wang, Mingyu 
> 
> Hi Tim
> 
> The answers to comment are as follows.
> 
> > +++ b/engine/tests/Functional.bind/data/linux_test.com.db_24
> > @@ -0,0 +1,10 @@
> > +$TTL    86400
> > +@               IN SOA  linux-test.com. root.linux-test.com. (
> > +                                        42              ; serial (d. adams)
> > +                                        3H              ; refresh
> > +                                        15M             ; retry
> > +                                        1W              ; expiry
> > +                                        1D )            ; minimum
> > +                IN NS           linux-test.com.
> > +		IN MX 10	linux-test.com.
> > +@		IN A	        192.168.246.87
> 
> >Does this test require that the device under test be on the 192.168
> network?
> >I'm not familiar enough with named and bind to know.
> 
> > +}
> > +
> > +function test_deploy {
> > +    put $TEST_HOME/bind_test.sh $BOARD_TESTDIR/fuego.$TESTDIR/
> > +    put $FUEGO_CORE/engine/scripts/fuego_board_function_lib.sh
> > $BOARD_TESTDIR/fuego.$TESTDIR
> > +    put -r $TEST_HOME/tests $BOARD_TESTDIR/fuego.$TESTDIR/
> > +    put -r $TEST_HOME/data $BOARD_TESTDIR/fuego.$TESTDIR/
> > +}
> > +
> > +function test_run {
> > +    report "cd $BOARD_TESTDIR/fuego.$TESTDIR;\
> > +    export tst_bind_file=246.168.192.in-addr.arpa.db;\
> 
> >will this work on a board on any network?  Or does the board being
> >tested have to be on a 192.168.246 network?
> 
> 
> The test can work on a board on any network.
> I will set the value of network in the board with a variable so that the user
> can make changes according to the actual test environment.
> 
> 
> >Would be good to check for pgrep here.  It is not a command that is
> common
> >to some of the very low-end systems, and it is used extensively throughout
> >the subtests.
> >It might be possible to write a simple shell function to perform the same
> >operation as pgrep (at least the way it is used now, which is limited
> >to just grep'ping ps for a single program name (ie - not using any of the
> >flags for filtering the process list by other attributes).
> >This would be a good candidate to put into fuego_board_function_lib.sh,
> >to provide this feature if pgrep is not present on a board.  (Then we
> wouldn't
> >be dependent on pgrep being present).
> 
> Using pgrep here is just to delete the named process without any other
> functions.
> Therefore, killall -9 named can be used instead.
> 
> 
> >Does this remove anything from the board that this test did not
> >put there?  If so, that's bad.  We should try to leave the board in
> >the same state we left it.  If /var/named existed before this test
> >was run, we should not be destroying it at the end of this test.
> 
> Yes. I plan to check whether /var/named exists first, and if there is, backup it
> first.
> After the test is completed, resume it.
> 
> >Does this test require root privileges to perform all these
> >operations (particularly the chown)?  If so, there should
> >be a NEED_ROOT=1 in fuego_test.sh to indicate this.
> 
> Control of service needs root permissions.
> Therefore, I will add NEED_ROOT=1 to fuego_test.sh.
> 
> 
> >If named was running before this test started, it should be restarted
> >when the test finishes, after all the configuration files have been restored.
> Yes, I will check if named was running before this test started.
> If it was running, when the test finishes, I will restart it, after all the
> configuration files have been restored.
> 
> If you agree with my above modifications, I'll modify the test suite and
> submit the patch.

I agree with this.  Please submit a patch with the proposed changes.
 -- Tim