<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [Twg] stand alone testing</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>maybe it is time to gather requirements for new tool/framework and describe new methodology? Or we will just improve old one and thats all?<BR>
<BR>
Seems that it hard to build good interfaces on sh (between configuration and script, between script and libs),<BR>
and to not leave chance for bugs we need to use some that will provide interfaces in it structure.<BR>
<BR>
As for methodology, seems that now we have only functional testing and some part of performance testing.<BR>
Maybe it is time to describe methodology and answer what we are missing (ut, sqv) and what coverage we have.<BR>
<BR>
<BR>
Denis<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: twg-bounces@lists.opensfs.org on behalf of Chris<BR>
Sent: Wed 5/16/2012 1:18 PM<BR>
To: Bruce Korb<BR>
Cc: twg@lists.opensfs.org<BR>
Subject: Re: [Twg] stand alone testing<BR>
<BR>
On 15/05/2012 19:39, Bruce Korb wrote:<BR>
> Hi Chris,<BR>
><BR>
> On 5/15/12 10:02 AM, Chris wrote:<BR>
>>> This does not prevent any of these phases from being in a library<BR>
>>> for use by any test, but it would mean that a given test cannot<BR>
>>> presuppose that some other test had been run before it.<BR>
>> One problem with this approach and looking at the history of the current<BR>
>> bash code is that it will lead to duplication via copy and paste because<BR>
>> people won't write libraries, bash does not lend itself to this and so<BR>
>> solutions will be messy.<BR>
> Bash *does* lend itself to libraries, but it is not a well understood<BR>
> technique. Shell scripts, by and large, do tend to be messy, but that<BR>
> is really much more a matter of education and technique than it is<BR>
> of inherent capabilities.<BR>
><BR>
> Due to scripting misuse, using another tool less prone to messy source<BR>
> seems like a reasonable approach. But the issue is not that of<BR>
> inadequacies<BR>
> of bash.<BR>
><BR>
><BR>
I absolutely agree Bruce and what we should learn from the last 10 years<BR>
of Lustre and by looking at 37000 lines of bash code is that people<BR>
don't do the right big picture thing when it comes to test scripts and<BR>
so I want us to adopt approaches that tend to cause the right thing to<BR>
happen.<BR>
<BR>
If we declare that all test scripts and modifications will now be<BR>
written in a structured, clear, well documented manner where duplicate<BR>
functionality is pulled out into libraries, variables are never<BR>
duplicate, naming is consistent... then I would have less concerns and<BR>
we would have more degrees of freedom. But can't actually do that and<BR>
so methods that encourage reuse and discourage code replication are a must.<BR>
<BR>
I also absolutely think we need to begin the work of creating a whole<BR>
new methodology (not to replace the bash but to provide for new tests)<BR>
that provides another tool less prone to messy source and structure.<BR>
Getting this right will be difficult because we need to provide for all<BR>
the freedom that developers require whilst constraining them into<BR>
something that over the next 10 years leads to an ordered outcome.<BR>
<BR>
Chris<BR>
<BR>
_______________________________________________<BR>
twg mailing list<BR>
twg@lists.opensfs.org<BR>
<A HREF="http://lists.opensfs.org/listinfo.cgi/twg-opensfs.org">http://lists.opensfs.org/listinfo.cgi/twg-opensfs.org</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>