<tt><font size=2>Dean Troyer <dtroyer@gmail.com> wrote on 02/26/2014
03:28:04 PM:<br>
<br>
> On Wed, Feb 26, 2014 at 1:09 PM, Mike Spreitzer <mspreitz@us.ibm.com>
wrote:</font></tt>
<br><tt><font size=2>>> Thanks for the further updates.  I have
just one question about <br>
>> those.  One way to do both unit testing and system (integration)
<br>
>> testing is to: git clone your favorite project to make a working
<br>
>> local repo somewhere on your testing machine, edit and commit
there,<br>
>> then use DevStack to create a running system in /opt/stack using
<br>
>> your modified project in place of the copy at git.openstack.org.
</font></tt>
<br><tt><font size=2>> <br>
> Yes, that is similar to what Sean mentioned, the difference being
<br>
> that his repos are actually in VirtualBox Shared Folders so the <br>
> Linux VM has access to them. He works on them natively on his laptop<br>
> so the VM doesn't need his desktop toolset installed.</font></tt>
<br>
<br><tt><font size=2>Sounds like he does unit testing in the VM and editing
in the host laptop.  In other words, the things we are documenting
(testing) are all done in the VM.</font></tt>
<br>
<br><tt><font size=2>>>  I think the most direct approach would
be to generalize the title of <br>
>> </font></tt><a href=https://wiki.openstack.org/wiki/Gerrit_Workflow#Unit_Tests_Only><tt><font size=2>https://wiki.openstack.org/wiki/Gerrit_Workflow#Unit_Tests_Only</font></tt></a><tt><font size=2>
and <br>
>> generalize the introductory remark to include a reference to <br>
>> </font></tt><a href=https://wiki.openstack.org/wiki/Testing#Indirect_Approach><tt><font size=2>https://wiki.openstack.org/wiki/Testing#Indirect_Approach</font></tt></a><tt><font size=2>
.  Does <br>
>> this make sense to you? </font></tt>
<br><tt><font size=2>> <br>
> Sure.  My edits were prompted by the loss of some information
useful<br>
> to making a choice between the two and tweaking the phrasing and sections.</font></tt>
<br><tt><font size=2>> <br>
> There are a lot of ways to do this, enumerating them is beyond the
<br>
> scope of that doc IMHO.  I think having the basic components/<br>
> requirements available should be enough, but then I also have my <br>
> workflow figured out so i probably am still missing something.</font></tt>
<br>
<br><tt><font size=2>Sure, documenting all the possible tropes and tweaks
(such as editing shared files on another machine) is not needed.  I
think documenting the basic ideas is helpful to newbies.</font></tt>
<br>
<br><tt><font size=2>>> As far as my experience goes, the fix to
1203680 would also cover <br>
>> 1203723: the only thing I find lacking for nova unit testing in
<br>
>> Ubuntu is libmysqlclient-dev, which is among the testing <br>
>> requirements of glance (see DevStack's files/apts/glance). </font></tt>
<br><tt><font size=2>>> <br>
>> As far as I can tell, Sean Dague is saying the fix to 1203680
is <br>
>> wrong because it binds unit testing to DevStack and he thinks
unit <br>
>> testing should be independent of DevStack. </font></tt>
<br><tt><font size=2>> <br>
> Let me summarize: "Unit testing is not a default requirement
for <br>
> DevStack.</font></tt>
<br>
<br><tt><font size=2>But do we stipulate the converse: shall DevStack be
a requirement for unit testing?  That is what I think Sean is objecting
to.  But I am getting weary and wary of speaking so much on his behalf.
 I wonder if anyone else wants to chime in on this.</font></tt>
<br>
<br><tt><font size=2>If the only people who speak up think that DevStack
should be a requirement for unit testing then this should be documented,
and I am likely to do so.</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>