Open Stack

On 02/27/2014 12:52 AM, Mike Spreitzer wrote:
> Dean Troyer <dtroyer at gmail.com> wrote on 02/26/2014 03:28:04 PM:
> 
>> On Wed, Feb 26, 2014 at 1:09 PM, Mike Spreitzer <mspreitz at us.ibm.com>
> wrote:
>>> Thanks for the further updates.  I have just one question about
>>> those.  One way to do both unit testing and system (integration)
>>> testing is to: git clone your favorite project to make a working
>>> local repo somewhere on your testing machine, edit and commit there,
>>> then use DevStack to create a running system in /opt/stack using
>>> your modified project in place of the copy at git.openstack.org.
>>
>> Yes, that is similar to what Sean mentioned, the difference being
>> that his repos are actually in VirtualBox Shared Folders so the
>> Linux VM has access to them. He works on them natively on his laptop
>> so the VM doesn't need his desktop toolset installed.
> 
> 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.

No, actually I usually do unit testing on laptops / desktops. There is
no reason to take VM overhead for unit tests when I've got a perfectly
working local env that can run tox. :)

The point is a ton of code is fixable / testable in the small. Then
exposing to a full environment once you've gotten it solid shape.

>>>  I think the most direct approach would be to generalize the title of
>>> https://wiki.openstack.org/wiki/Gerrit_Workflow#Unit_Tests_Onlyand
>>> generalize the introductory remark to include a reference to
>>> https://wiki.openstack.org/wiki/Testing#Indirect_Approach.  Does
>>> this make sense to you? 
>>
>> Sure.  My edits were prompted by the loss of some information useful
>> to making a choice between the two and tweaking the phrasing and
> sections.
>>
>> There are a lot of ways to do this, enumerating them is beyond the
>> scope of that doc IMHO.  I think having the basic components/
>> requirements available should be enough, but then I also have my
>> workflow figured out so i probably am still missing something.
> 
> 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.
> 
>>> As far as my experience goes, the fix to 1203680 would also cover
>>> 1203723: the only thing I find lacking for nova unit testing in
>>> Ubuntu is libmysqlclient-dev, which is among the testing
>>> requirements of glance (see DevStack's files/apts/glance). 
>>>
>>> As far as I can tell, Sean Dague is saying the fix to 1203680 is
>>> wrong because it binds unit testing to DevStack and he thinks unit
>>> testing should be independent of DevStack.
>>
>> Let me summarize: "Unit testing is not a default requirement for
>> DevStack.
> 
> 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.
> 
> 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.

Right, that's what I object to. Because it's not a requirement for unit
testing. A requirement for unit testing is just that you run an
operating system that has basic tools, and that you can install pip and
tox == 1.6 in that environment.

Individual unit tests have additional requirements, but they don't
require a big running devstack environment. That's *one* way you might
decide to build such a thing, but it's really not the best way.

I think what you probably actually want is some way to let/make tox
actually install the -dev packages that are needed to run the unit tests
in questions. That's something I think monty has thought about in the
past. And I agree, that would probably be handy.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 478 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140227/b4615e1d/attachment.pgp>