2001-06

<body stylesrc="index.html" background="images/Bkgrnd02T2.gif"> <table border="0" cellpadding="6" cellspacing="0" width="810"> <tr> <td align="right" valign="top" height="1" width="161"> <p align="center"><img border="0" src="images/Accent03.gif" align="left" width="142" height="37"> </p> <p align="left"><b><font size="2">June 2001 - Vol. 2 No. 6</font></b></p> </td> <td height="1" width="621"> <p align="center">  <a href="index.html" target="_top">[Home]</a> <a href="Newsletters.html" target="_top">[Up]</a> <a href="2001-07.html" target="_top">[Next]</a> <a href="2001-05.html" target="_top">[Previous]</a></td> </tr> <tr> <td valign="top" height="529" bgcolor="#FFFFCC" width="161"> <font size="2"> <p><a href="#TechTalk"><b>Tech Talk</b></a><br> <a href="#Unit Testing with Complex Objects">Unit Testing with Complex Objects</a> </p> <p><a href="#Editorial"><b>Editorial</b></a><br> <a href="#C++ Standards Meeting Report">C++ Standards Meeting Report</a> </p> <p><a href="#Trends"><b>Trends</b></a><br> </font> <a href="#Job Openings">Job Openings<br> </a><a href="#SourceForge Statistics">SourceForge Statistics</a></p> <p>  </td> <td height="277" bgcolor="#FFCC99" width="621"> <b> <h1><a name="TechTalk"><font color="#000000">Tech Talk</font></a></h1> <h2><font face="Arial" color="#000000"><a name="Unit Testing with Complex Objects">Unit Testing with Complex Objects</a></font></h2> </b> <i><font SIZE="2"> <p>By </font><a href="Author-RegCharney.html">Reg. Charney</a></p> </i> <b> <i><font FACE="Arial" SIZE="2"> <h3>Unit Testing, An Introduction</h3> </font></i> </b> <p>I am defining a unit as a program or function that uses some objects to do a task. These objects are non-trivial and require preparation in terms of setting up their constructor arguments before they can be instantiated. Further, we know that individual classes have been tested and we know they work. What we are trying to do is put them all together into meaningful whole. We are also trying to avoid embedding the unit into a massive system. There are several reasons for doing this, including the main system does not work yet, or it takes up a lot of resources, etc. We also want the testing to be as quick and simple as possible while giving meaningful results.</p> <b> <i><font FACE="Arial" SIZE="2"> <h4>Music Site Example</h4> </font></i> </b> <p>As part of our music site, our unit test logs in users, loads their preferences and extracts matching music from a database. The objects come from an authentication class, a user class, a preference class, and a database class.</p> <p>These classes have different characteristics. If the <font FACE="Courier New">Database </font>can not be found or accessed, the unit fails catastrophically (I.e., an <font FACE="Courier New">assert </font>fails.) Similarly for the <font FACE="Courier New">Auth </font>class. If no preferences can be found for a user, a default <font FACE="Courier New">Pref </font>instance is acceptable. If a <font FACE="Courier New">User </font>fails, only an indicator is needed because the user can try up to <font FACE="Courier New">n</font> times, depending on parameter.</p> <p>In pseudo-code, here is the unit:</p> <b> <div align="center"> <center> <table border="1" bgcolor="#FFFFFF"> <tr> <td> <b> <font FACE="Courier New">string dbname, uid;<br> cout << </font>"<font FACE="Courier New">Enter db name:</font>"<font FACE="Courier New">;<br> cin >> dbname;<br> Database db(dbname);</font> </b> <p> <b> <font FACE="Courier New">cout << </font>"<font FACE="Courier New">Enter your id:</font>"<font FACE="Courier New">;<br> cin >> uid;<br> Auth a(uid, 3);<br> Preference p(a);</font> </b> </p> <p> <b> <font FACE="Courier New">Selection s(db, p);</font> </b> </td> </tr> </table> </center> </div> </b> <p>In this example, <font FACE="Courier New">Database db</font> needs a string for its name/path. <font FACE="Courier New">Auth a </font>needs a string, <font FACE="Courier New">Preference p </font>needs a user, and <font FACE="Courier New">Selection s </font>needs both a database object and a preference set. There is a lot of setup needed to test the viability of selection <font FACE="Courier New">s</font>. Wouldn’t it be simpler to write something like this that would do the same thing?</p> <b> <div align="center"> <center> <table border="1" bgcolor="#FFFFFF"> <tr> <td> <b> <font FACE="Courier New">TDatabase db;<br> TAuth a;<br> TPreference p(a);<br> TSelection s(db, p);</font> </b> </td> </tr> </table> </center> </div> </b> <p>The sample above shows what you can do with test classes. These are classes that you design when you design the real classes. Notice that the default test class constructors do what you want and expect. This article discusses how you can do this.</p> <b> <i><font FACE="Arial" SIZE="2"> <h3>Construction Techniques</h3> </font></i> </b> <p>There are two techniques used to construct an object: the normal constructor method; and the static create method. The normal constructor method usually appears in one of two ways:</p> <div align="center"> <center> <table border="1" bgcolor="#FFFFFF"> <tr> <td> <b> <font FACE="Courier New">class X { /* . . . */ };<br> X x(a1, a2);<br> X px = new X(a1, a2, a3);</font> </b> </td> </tr> </table> </center> </div> <p>The number of constructor arguments vary by class and application use. With this method, failure to construct an object can only be detected by: (i) throwing an exception; (ii) terminating the process; or (iii) using a status variable. (Note: failure may be independent of the allocation of object storage.)</p> <p>The second technique uses a static create function for the class.</p> <b> <div align="center"> <center> <table border="1" bgcolor="#FFFFFF"> <tr> <td> <b> <font FACE="Courier New">class X {<br>   public:<br>     static X* create(int a)<br>     { return a ? new X : 0; }<br>     // . . .<br>   private:<br>     X() { cout << </font>"<font FACE="Courier New">In X\n</font>"<font FACE="Courier New">; }<br> };<br> // . . .<br> A a;<br> X px = X::create(a);</font> </b> </td> </tr> </table> </center> </div> </b> <p>An instance of the class <font FACE="Courier New">X</font> is created only under some precondition, like when <font FACE="Courier New">a</font> evaluates to non-zero . Otherwise, the create function returns null.</p> <b> <i> <h4><font face="Arial">Basic Testing Technique</font></h4> </i> </b> <p>We use derivation to create test classes because they satisfy the “is-a” criteria. Any derivative is an instance of a base class. Thus, anything that you do to a base class instance, you can also do to a derived class instance. For example,</p> <div align="center"> <center> <table border="1" bgcolor="#FFFFFF"> <tr> <td> <b> <font FACE="Courier New">class B { /* . . . */ };<br> class TB : public B { };<br> <br> void foo(B& b);<br> void bar(B* pb);<br> <br> B b, bp = &b;<br> TB tb, ptb = &tb;<br> <br> foo(tb);<br> bar(ptb);</font> </b> </td> </tr> </table> </center> </div> <p>Both <font FACE="Courier New">foo() </font>and <font FACE="Courier New">bar() </font>work as well with a <font FACE="Courier New">TB</font> as with a <font FACE="Courier New">B</font>. Thus, we can use a <font FACE="Courier New">TB </font>as easily as a <font FACE="Courier New">B</font>. This is the basis of our testing technique. This article shows how we can easily create derived test classes from normal class.</p> <b> <i> <h4><font face="Arial">Simple Derivation</font></h4> </i> </b> <p>Going back to the music example, we can see that a <font FACE="Courier New">Pref </font>class can return a default preference object if the user has no preferences.</p> <b> <div align="center"> <center> <table border="1" bgcolor="#FFFFFF"> <tr> <td> <b> <font FACE="Courier New">class Pref {<br>   public:<br>     typedef list<Music*> LM;<br>     Pref() { /* . . . */ };<br>     Pref(Auth& a)<br>     { lm = rdPref(a.path); }<br>   private:<br>     LM lm;<br>     LM rdPref(const string &s);<br> };</font> </b> </td> </tr> </table> </center> </div> </b> <p>This is the simplest case for creating a test class. In fact, a test class is not really needed—we can just use the actual class. However, a normal default preference may not be very interesting. For example, it may be the same as no preference, which means that it looks like it does not even exist. Thus, tests based on such a preference would not be very useful. Better would be a dummy set of preferences that would be non-empty and valid.</p> <p>In this simple case, Step 1 would be to introduce a <font FACE="Courier New">protected</font> constructor that does nothing.. It needs a signature that distinguishes it from any other constructor. Step 2 would be to define a derived class that loads a sample preference list.</p> <b> <div align="center"> <center> <table border="1" bgcolor="#FFFFFF"> <tr> <td> <b> <font FACE="Courier New">class Pref {<br>   public:<br>     typedef list<Music*> LM;<br>     Pref() { /* . . . */ };<br>     Pref(Auth& a)<br>     { lm = rdPref(a.pathm); }<br>   private:<br>     LM lm;<br>     LM rdPref(const string &s);<br>   protected: // test only<br>     Pref(int) { /* empty */ }<br> };<br> <br> #include <new><br> class TPref : public Pref<br> {<br>   public:<br>     TPref() : Pref(0)<br>     {<br>       Auth a(</font>"<font FACE="Courier New">validAuth</font>"<font FACE="Courier New">);<br>       ((Pref*)this)->~Pref();<br>       new(this) Pref(a);<br>     }<br> };</font> </b> </td> </tr> </table> </center> </div> </b> <p>Here, <font FACE="Courier New">TPref </font>invokes the constructor that does nothing, defines an authorized user using a known valid test user, destroys the empty object part of itself, and then creates a valid <font FACE="Courier New">Pref </font>instance on top of itself. Now we can use <font FACE="Courier New">TPref </font>anywhere that we could use <font FACE="Courier New">Pref</font> — even the address has remainder the same. Please note the <font FACE="Courier New">#include <new></font>. It is needed for the placement <font FACE="Courier New">new</font>.</p> <b> <h3><font face="Arial">Static Create function Technique</font></h3> </b> <p>Recall that the <font FACE="Courier New">Auth </font>class needs to get a valid user. If an invalid user is entered, another <font FACE="Courier New">n-1 </font>tries are made. Thus, we want a way of signally that the given string does not represent a valid <font FACE="Courier New">User</font>. In such a case, the static create technique can come in handy.</p> <div align="center"> <center> <table border="1" bgcolor="#FFFFFF"> <tr> <td> <b> <font FACE="Courier New">class User {<br>   public:<br>     static User* create(string& s)<br>     {<br>       bool b = valid(s);<br>       return b?new User(s):0;<br>     }<br>     void doSomething();<br>   private:<br>     User(string& s) { uid=s; }<br>     bool valid(string s);<br>     string uid;<br> };<br> <br> cout << </font>"<font FACE="Courier New">Enter id:</font>"<font FACE="Courier New">;<br> cin >> s;<br> User *pU = User::create(s);<br> <br> if (pU) { // valid user<br>   pU->doSomething(); <br> }</font> </b> </td> </tr> </table> </center> </div> <p>Since the test class should support the same constructor interface as the base class, we need a static class <font FACE="Courier New">create </font>function. We are also going to use the placement <font FACE="Courier New">new </font>trick that we used earlier, only its going to be a little more complicated—but just a little. As before, we added a do-nothing base class constructor different from any potential default base constructor.</p> <b> <div align="center"> <center> <table border="1" bgcolor="#FFFFFF"> <tr> <td> <b> <font FACE="Courier New">class User {<br>   public:<br>     static User* create(string& s)<br>     {<br>       bool b = valid(s);<br>       return b?new User(s):0;<br>     }<br>     void doSomething();<br>   private:<br>     User(string& s) { uid=s; }<br>     static bool valid(char*s);<br>     string uid;<br>   protected: // test only<br>     User(int) { /* empty */ }<br> };</font> <p><font FACE="Courier New">#include <new><br> class TUser : public User {<br>   public:<br>     static TUser* create(string& s)<br>     {<br>       return (TUser*)<br>       User::create(s);<br>     }<br> };<br> <br> cout << </font>"<font FACE="Courier New">Enter id:</font>"<font FACE="Courier New">;<br> cin >> s;<br> TUser *pU=TUser::create(s);<br> if (pU) { // valid user<br>   pU->doSomething();<br> }</font> </b> </td> </tr> </table> </center> </div> </b> <p>This is simple and works fine. However, it does not support a default constructor for the test class. First, notice that class <font FACE="Courier New">User </font>already has a constructor, but its <font FACE="Courier New">private</font>. To make the <font FACE="Courier New">User </font>constructors we need available to the test class <font FACE="Courier New">TUser</font>, the easiest solution is to declare <font FACE="Courier New">TUser </font>a <font FACE="Courier New">friend </font>class. This makes them available to any derived test class. Also, lets make all validation functions static. (Note, we have already separated data validation from the allocation of the memory in the <font FACE="Courier New">create </font>function.)</p> <b> <div align="center"> <center> <table border="1" bgcolor="#FFFFFF"> <tr> <td> <b> <font FACE="Courier New">class User {<br>     friend class TUser;<br>   public:<br>     static User* create(string& s)<br>     {<br>       bool b = valid(s);<br>       return b?new User(s):0;<br>     }<br>     void doSomething();<br>   private:<br>     string uid;<br>     User(string& s) { uid=s; }<br>     static bool valid(char*s);<br>     User(int) { /* empty */ }<br> };<br> <br> #include <new><br> class TUser : public User {<br>   public:<br>     // Assume Ed always valid<br>     TUser(char* s=</font>0<font FACE="Courier New">):User(0)<br>     {<br>       string ss;<br>       ss = (s) ? s : </font>""<font FACE="Courier New">;<br>       if (ss == </font>""<font FACE="Courier New">) ss = </font>"Ed"<font FACE="Courier New">;<br>         ((User*)this)->~User();<br>       assert(valid(ss));<br>       new(this) User(ss);<br>     }<br>     static<br>     TUser* create(string& s)<br>     {<br>       return (TUser*)User::create(s);<br>     }<br> };<br> <br> TUser tu; // valid user Ed<br> tu.doSomething();</font> </b> <p> <b> <font FACE="Courier New">cout << </font>"<font FACE="Courier New">Enter id:</font>"<font FACE="Courier New">;<br> cin >> s;<br> TUser *pU=TUser::create(s);<br> <br> if (pU) { // valid user<br>   pU->doSomething(); <br> }</font> </b> </td> </tr> </table> </center> </div> </b> <p>Note the default <font FACE="Courier New">TUser </font>constructor invokes the do-nothing <font FACE="Courier New">User </font>constructor explicitly. The empty <font FACE="Courier New">User </font>that is initially constructed as part of <font FACE="Courier New">TUser </font>can also be destroyed. Since this part of the code is a constructor, if <font FACE="Courier New">valid() </font>returns a false, the assertion fails. Else, we can construct the new instance on top of ourselves. Again, remember to <font FACE="Courier New">#include <new></font> to use the placement <font FACE="Courier New">new </font>operator. I can also safely cast up from a <font FACE="Courier New">User </font>to a <font FACE="Courier New">TUser </font>since <font FACE="Courier New">TUser </font>has no member data.</p> <p>To summarize this technique, I defined a derived test class with a default constructor and a public static create function. I also made the test class a friend of the base class. As part of the test class, a valid user value was inserted if no user id was supplied. As a result of all this is that the test class can be used wherever the original base class can be used. It can also be used with a default constructor.</p> <i> <p>The music example was inspired by my neighbor Marietta and her kids, Kelly and Robert, and a delightful Sunday Peninsula Youth Orchestra concert. ( <a href="http://www.peninsulasym.org">www.peninsulasym.org</a> ) Thanks.</p> </i> <b> <h1><font color="#000000"><a name="Editorial">Editorial</a></font></h1> </b> <i> <p>By <a href="Author-RegCharney.html">Reg. Charney</a></p> </i> <b> <h3><font face="Arial"><a name="C++ Standards Meeting Report">C++ Standards Meeting Report</a></font></h3> </b> <p>Early this month I attended the C++ Standards Working Group (WG21) in Copenhagen. It was held at the Danish Standards (DS) locale on the outskirts of the city. In getting to the meeting place by train, two things were noticeable: the trains ran on time and the ticketing system they used was very neat. Ask if you are interested.</p> <p>I attended the Library Working Group for the week, although I normally attend the Core group. Most of the recent “exciting work” has been done in the Library Working Group (lwg) and I wanted to get a better feel for what has been happening there.</p> <p>In summary three things have come out of this meeting:</p> <p>1) We are within one meeting of issuing the next Technical Report on the C++ Standard containing corrections and clarifications. As voting members of WG21, we will have access to the Working Draft of the TR that should be ready within 60 days.</p> <p>2) Bjarne gave a presentation on his vision of the Future Directions of C++. Bjarne may have posted his slides on his web site by the time you read this.</p> <p>3) Based on a number of Bjarne's comments and other issues that have come up over the last couple of years, we are going to resurrect the Extensions Working Group to consider things like his eXtensions Language Interface (XLI).</p> <b><i> <h1><font color="#000000"><a name="Trends">Trends</a></font></h1> </i></b><i> <p>By <a href="Author-RegCharney.html">Reg. Charney</a></p> </i> <b><i> <p><font FACE="Arial"><a name="Job Openings">Job Openings</a></font></p> </i></b> <p>This is another month of declining job openings. There was a 15.8% decline in Silicon Valley IT job openings since last month. Nationwide, the decline was 16.9%. The only positive trends were in the Windows 2000 arena. </p> <p align="center"><img border="0" src="images/2001-06-Fig01.gif" align="center" width="462" height="342"></p> <p align="center"><img border="0" src="images/2001-06-Fig02.gif" width="462" height="292"></p> <p>From the charts above, you can see that the growth in demand for Windows 2000 skills are increasing at an accelerating rate. The most dramatic falloff is in the Linux space. While demand is still strong for Linux, the continued demand is falling off. It is my contention that Linux is a “early adopter” phenomena. As such, people take a chance on things like Linux while times are good and retreat from chancy ventures when things are tough.</p> <b><i> <p><font FACE="Arial"><a name="SourceForge Statistics">SourceForge Statistics</a></font></p> </i></b> <p>Since last month the number of projects has increate 5.8% and the number of users has increased by 9.2%. The most popular projects downloaded this month are the CDex project, a CD-Ripper that extracts digital audio data from an Audio CD. The GPL Windows application supports many Audio encoders, like MPEG (MP2,MP3), VQF, AAC encoders. The second most popular download is MiKTeX, an up-to-date implementation of TeX & Friends for Windows (all current variants). The third most popular project is MyNapster, a Win32 client using Gnutella and IRC for chat. It is based on Gnucleus and utilizes MFC (works with WINE).</p> <p>Note that these projects are meant to run under Windows, not Linux.</p> <p>By project type, the projects on SourceForge are:</p> <div align="center"> <center> <table border="1" bgcolor="#FFFFFF"> <tr> <td>Communications </td> <td align="right">2564 projects</td> </tr> <tr> <td>Database</td> <td align="right">984 projects</td> </tr> <tr> <td>Desktop Environ</td> <td align="right">678 projects</td> </tr> <tr> <td>Education</td> <td align="right">465 projects</td> </tr> <tr> <td>Games/Entertainment</td> <td align="right">2339 projects</td> </tr> <tr> <td>Internet</td> <td align="right">3675 projects</td> </tr> <tr> <td>Multimedia</td> <td align="right">1998 projects</td> </tr> <tr> <td>Office/Business</td> <td align="right">683 projects</td> </tr> <tr> <td>Other/Non-listed</td> <td align="right">461 projects</td> </tr> <tr> <td>Printing</td> <td align="right">77 projects</td> </tr> <tr> <td>Religion</td> <td align="right">48 projects</td> </tr> <tr> <td>Scientific/Engineering</td> <td align="right">1220 projects</td> </tr> <tr> <td>Security</td> <td align="right">406 projects</td> </tr> <tr> <td>Sociology</td> <td align="right">27 projects</td> </tr> <tr> <td>Software Development</td> <td align="right">2566 projects</td> </tr> <tr> <td>System</td> <td align="right">3068 projects</td> </tr> <tr> <td>Terminals</td> <td align="right">106 projects</td> </tr> <tr> <td>Text Editors</td> <td align="right">386 projects</td> </tr> </table> </center> </div> <p>As an aside, the story I heard about CDex is that they wrote to the RIAA (Record Industry Association of America) asking what CDs they could index and the RIAA replied by suing them. Ah, thank God for lawyers.</p> <b><font SIZE="2"> <h1>Correction:</h1> </font></b> <p>In the last month’s article, I changed the fourth example to say: ^[^\s]*</p> <p>Jesse corrected me. It should have been: ^[^ ]+. He said, “I did not use the '\s' because that is not in all regex engines. It should be '+' rather than '*' because we want a positive grab.</p> </td> </tr> </table> </body>