You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Matthew Morrissey <ma...@sungard.com> on 2012/10/30 15:34:33 UTC
Unit tests
Hello all,
I would like to begin writing unit tests for api/src/com/cloud/api and I
wanted to make sure that 1) it's an acceptable idea to everyone and 2) I
get the directory structure correct. I have seen a few emails about the
possible structure but no concrete "this is the way to go" type statements.
My thought is that these tests would be in
api/src/test/java/com/cloud/api/*.java. Is this the right line of thought?
Please let me know and I'll get the ball rolling. I've got a long way to go
if I want to catch up to Yichi :)
--
Matthew Morrissey
Software Engineer - SunGard Availability Services - 401 N. Broad Street,
Philadelphia, PA 19108
o: 215-446-2713 - e: matthew.morrissey@sungard.com
Re: [DISCUSS]How to write API Unit Tests
Posted by Prasanna Santhanam <pr...@citrix.com>.
On Wed, Nov 28, 2012 at 06:58:14AM +0530, David Nalley wrote:
> On Tue, Nov 27, 2012 at 6:09 PM, Min Chen <mi...@citrix.com> wrote:
> > Hi there,
> >
> > In working with API refactoring work, I cannot help wondering how we
> > should write Junit test cases for our APIs. Recently I saw that Chip has
> > merged some of his API unit test cases into master branch, and his api
> > unit test cases are written using Mockito, so no DB and real MS are needed
> > in running these Junit test cases. Here I want to raise this topic again
> > to get some clarifications on api unit test guidelines:
> > 1. Should we require API unit test cases to be able to run without DB
> > existing or MS running?
> > 2. If answer is yes, then I guess that we just need to use Mockito to
> > write our api unit test cases.
> > 3. If answer is no, there are several follow-up questions to be clarified:
> > 1) Does test case itself need to handle starting MS and stopping MS?
> > 2) How should we set up a test DB? This may be needed for those list
> > APIs.
> > 3) Testcases need to handle tear down test data afterwards.
> >
> > Thanks
> > -min
> >
>
> So unit tests (IMO) should not need external resources to run, should
> be very fast, etc as Sudha has indicated.
>
> If you need DB access, that sounds much more like a
> functional/integration test to my ears.
>
IMO if any layer should be unittest-able it should be the API. But if
that's not possible if we stray away from the purist view of a
unittest ie w.o the DB then we could run the tests against a database
populated by the simulator. For the 300 or so APIs to be backed with
unittests the simulator can easily produce various configurations of
cloudstack with different zone models.
The functional/integration suite does *NOT* test the API the way I
would imagine we should test the API. For the API tests to be tested
functionally over the course of this refactor we will need to ensure
all request/response arguments and params remain undisturbed. And this
is not something the integration suite does today. But it certainly
can.
--
Prasanna.,
Re: [DISCUSS]How to write API Unit Tests
Posted by Min Chen <mi...@citrix.com>.
Sorry, typo, I meant "so no functional test cases are needed to be added
here".
Thanks
-min
On 11/28/12 10:58 AM, "Min Chen" <mi...@citrix.com> wrote:
>Thanks Rayees. By looking into functional smoke testcase foler, we have
>already had functional test cases for listVmsCmd and listRoutersCmd, so
>new functional test cases are needed to be added here. I will add a simple
>Junit test case using mockito to complete the patch.
>
>-min
>
>On 11/28/12 10:48 AM, "Rayees Namathponnan"
><ra...@citrix.com> wrote:
>
>>
>>Hi Min,
>>
>>Function test cases are available at
>>
>>ŠŠ.. Repo/incubator-cloudstack/test/integration/smoke
>>
>>
>>Regards,
>>Rayees
>>
>>
>>On 11/28/12 10:00 AM, "Min Chen" <mi...@citrix.com> wrote:
>>
>>>Thanks for the clarification.
>>>
>>>-min
>>>
>>>On 11/27/12 7:48 PM, "Chip Childers" <ch...@sungard.com> wrote:
>>>
>>>>+1 to what everyone is saying. This sounds like a functional test is
>>>>needed, along with a simple unit test for completeness.
>>>>
>>>>- chip
>>>>
>>>>Sent from my iPhone.
>>>>
>>>>On Nov 27, 2012, at 8:33 PM, Sudha Ponnaganti
>>>><su...@citrix.com> wrote:
>>>>
>>>>> Min,
>>>>>
>>>>> Here is the link to the current framework
>>>>> https://cwiki.apache.org/CLOUDSTACK/testing-with-python.html
>>>>>
>>>>> Also check out Rohit's CLI as well. That would also help to automate
>>>>>faster
>>>>>
>>>>> Thanks
>>>>> /Sudha
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Nalley [mailto:david@gnsa.us]
>>>>> Sent: Tuesday, November 27, 2012 5:28 PM
>>>>> To: cloudstack-dev@incubator.apache.org
>>>>> Subject: Re: [DISCUSS]How to write API Unit Tests
>>>>>
>>>>> On Tue, Nov 27, 2012 at 6:09 PM, Min Chen <mi...@citrix.com>
>>>>>wrote:
>>>>>> Hi there,
>>>>>>
>>>>>> In working with API refactoring work, I cannot help wondering
>>>>>> how we should write Junit test cases for our APIs. Recently I saw
>>>>>>that
>>>>>> Chip has merged some of his API unit test cases into master branch,
>>>>>> and his api unit test cases are written using Mockito, so no DB and
>>>>>> real MS are needed in running these Junit test cases. Here I want to
>>>>>> raise this topic again to get some clarifications on api unit test
>>>>>>guidelines:
>>>>>> 1. Should we require API unit test cases to be able to run
>>>>>> without DB existing or MS running?
>>>>>> 2. If answer is yes, then I guess that we just need to use
>>>>>> Mockito to write our api unit test cases.
>>>>>> 3. If answer is no, there are several follow-up questions to
>>>>>>be
>>>>>>clarified:
>>>>>> 1) Does test case itself need to handle starting MS and
>>>>>>stopping MS?
>>>>>> 2) How should we set up a test DB? This may be needed for
>>>>>> those list APIs.
>>>>>> 3) Testcases need to handle tear down test data
>>>>>>afterwards.
>>>>>>
>>>>>> Thanks
>>>>>> -min
>>>>>
>>>>> So unit tests (IMO) should not need external resources to run, should
>>>>>be very fast, etc as Sudha has indicated.
>>>>>
>>>>> If you need DB access, that sounds much more like a
>>>>>functional/integration test to my ears.
>>>>>
>>>>> --David
>>>>>
>>>
>>
>
Re: [DISCUSS]How to write API Unit Tests
Posted by Min Chen <mi...@citrix.com>.
Thanks Rayees. By looking into functional smoke testcase foler, we have
already had functional test cases for listVmsCmd and listRoutersCmd, so
new functional test cases are needed to be added here. I will add a simple
Junit test case using mockito to complete the patch.
-min
On 11/28/12 10:48 AM, "Rayees Namathponnan"
<ra...@citrix.com> wrote:
>
>Hi Min,
>
>Function test cases are available at
>
>ŠŠ.. Repo/incubator-cloudstack/test/integration/smoke
>
>
>Regards,
>Rayees
>
>
>On 11/28/12 10:00 AM, "Min Chen" <mi...@citrix.com> wrote:
>
>>Thanks for the clarification.
>>
>>-min
>>
>>On 11/27/12 7:48 PM, "Chip Childers" <ch...@sungard.com> wrote:
>>
>>>+1 to what everyone is saying. This sounds like a functional test is
>>>needed, along with a simple unit test for completeness.
>>>
>>>- chip
>>>
>>>Sent from my iPhone.
>>>
>>>On Nov 27, 2012, at 8:33 PM, Sudha Ponnaganti
>>><su...@citrix.com> wrote:
>>>
>>>> Min,
>>>>
>>>> Here is the link to the current framework
>>>> https://cwiki.apache.org/CLOUDSTACK/testing-with-python.html
>>>>
>>>> Also check out Rohit's CLI as well. That would also help to automate
>>>>faster
>>>>
>>>> Thanks
>>>> /Sudha
>>>>
>>>> -----Original Message-----
>>>> From: David Nalley [mailto:david@gnsa.us]
>>>> Sent: Tuesday, November 27, 2012 5:28 PM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Subject: Re: [DISCUSS]How to write API Unit Tests
>>>>
>>>> On Tue, Nov 27, 2012 at 6:09 PM, Min Chen <mi...@citrix.com> wrote:
>>>>> Hi there,
>>>>>
>>>>> In working with API refactoring work, I cannot help wondering
>>>>> how we should write Junit test cases for our APIs. Recently I saw
>>>>>that
>>>>> Chip has merged some of his API unit test cases into master branch,
>>>>> and his api unit test cases are written using Mockito, so no DB and
>>>>> real MS are needed in running these Junit test cases. Here I want to
>>>>> raise this topic again to get some clarifications on api unit test
>>>>>guidelines:
>>>>> 1. Should we require API unit test cases to be able to run
>>>>> without DB existing or MS running?
>>>>> 2. If answer is yes, then I guess that we just need to use
>>>>> Mockito to write our api unit test cases.
>>>>> 3. If answer is no, there are several follow-up questions to
>>>>>be
>>>>>clarified:
>>>>> 1) Does test case itself need to handle starting MS and
>>>>>stopping MS?
>>>>> 2) How should we set up a test DB? This may be needed for
>>>>> those list APIs.
>>>>> 3) Testcases need to handle tear down test data afterwards.
>>>>>
>>>>> Thanks
>>>>> -min
>>>>
>>>> So unit tests (IMO) should not need external resources to run, should
>>>>be very fast, etc as Sudha has indicated.
>>>>
>>>> If you need DB access, that sounds much more like a
>>>>functional/integration test to my ears.
>>>>
>>>> --David
>>>>
>>
>
Re: [DISCUSS]How to write API Unit Tests
Posted by Rayees Namathponnan <ra...@citrix.com>.
Hi Min,
Function test cases are available at
ŠŠ.. Repo/incubator-cloudstack/test/integration/smoke
Regards,
Rayees
On 11/28/12 10:00 AM, "Min Chen" <mi...@citrix.com> wrote:
>Thanks for the clarification.
>
>-min
>
>On 11/27/12 7:48 PM, "Chip Childers" <ch...@sungard.com> wrote:
>
>>+1 to what everyone is saying. This sounds like a functional test is
>>needed, along with a simple unit test for completeness.
>>
>>- chip
>>
>>Sent from my iPhone.
>>
>>On Nov 27, 2012, at 8:33 PM, Sudha Ponnaganti
>><su...@citrix.com> wrote:
>>
>>> Min,
>>>
>>> Here is the link to the current framework
>>> https://cwiki.apache.org/CLOUDSTACK/testing-with-python.html
>>>
>>> Also check out Rohit's CLI as well. That would also help to automate
>>>faster
>>>
>>> Thanks
>>> /Sudha
>>>
>>> -----Original Message-----
>>> From: David Nalley [mailto:david@gnsa.us]
>>> Sent: Tuesday, November 27, 2012 5:28 PM
>>> To: cloudstack-dev@incubator.apache.org
>>> Subject: Re: [DISCUSS]How to write API Unit Tests
>>>
>>> On Tue, Nov 27, 2012 at 6:09 PM, Min Chen <mi...@citrix.com> wrote:
>>>> Hi there,
>>>>
>>>> In working with API refactoring work, I cannot help wondering
>>>> how we should write Junit test cases for our APIs. Recently I saw that
>>>> Chip has merged some of his API unit test cases into master branch,
>>>> and his api unit test cases are written using Mockito, so no DB and
>>>> real MS are needed in running these Junit test cases. Here I want to
>>>> raise this topic again to get some clarifications on api unit test
>>>>guidelines:
>>>> 1. Should we require API unit test cases to be able to run
>>>> without DB existing or MS running?
>>>> 2. If answer is yes, then I guess that we just need to use
>>>> Mockito to write our api unit test cases.
>>>> 3. If answer is no, there are several follow-up questions to be
>>>>clarified:
>>>> 1) Does test case itself need to handle starting MS and
>>>>stopping MS?
>>>> 2) How should we set up a test DB? This may be needed for
>>>> those list APIs.
>>>> 3) Testcases need to handle tear down test data afterwards.
>>>>
>>>> Thanks
>>>> -min
>>>
>>> So unit tests (IMO) should not need external resources to run, should
>>>be very fast, etc as Sudha has indicated.
>>>
>>> If you need DB access, that sounds much more like a
>>>functional/integration test to my ears.
>>>
>>> --David
>>>
>
Re: [DISCUSS]How to write API Unit Tests
Posted by Min Chen <mi...@citrix.com>.
Thanks for the clarification.
-min
On 11/27/12 7:48 PM, "Chip Childers" <ch...@sungard.com> wrote:
>+1 to what everyone is saying. This sounds like a functional test is
>needed, along with a simple unit test for completeness.
>
>- chip
>
>Sent from my iPhone.
>
>On Nov 27, 2012, at 8:33 PM, Sudha Ponnaganti
><su...@citrix.com> wrote:
>
>> Min,
>>
>> Here is the link to the current framework
>> https://cwiki.apache.org/CLOUDSTACK/testing-with-python.html
>>
>> Also check out Rohit's CLI as well. That would also help to automate
>>faster
>>
>> Thanks
>> /Sudha
>>
>> -----Original Message-----
>> From: David Nalley [mailto:david@gnsa.us]
>> Sent: Tuesday, November 27, 2012 5:28 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [DISCUSS]How to write API Unit Tests
>>
>> On Tue, Nov 27, 2012 at 6:09 PM, Min Chen <mi...@citrix.com> wrote:
>>> Hi there,
>>>
>>> In working with API refactoring work, I cannot help wondering
>>> how we should write Junit test cases for our APIs. Recently I saw that
>>> Chip has merged some of his API unit test cases into master branch,
>>> and his api unit test cases are written using Mockito, so no DB and
>>> real MS are needed in running these Junit test cases. Here I want to
>>> raise this topic again to get some clarifications on api unit test
>>>guidelines:
>>> 1. Should we require API unit test cases to be able to run
>>> without DB existing or MS running?
>>> 2. If answer is yes, then I guess that we just need to use
>>> Mockito to write our api unit test cases.
>>> 3. If answer is no, there are several follow-up questions to be
>>>clarified:
>>> 1) Does test case itself need to handle starting MS and
>>>stopping MS?
>>> 2) How should we set up a test DB? This may be needed for
>>> those list APIs.
>>> 3) Testcases need to handle tear down test data afterwards.
>>>
>>> Thanks
>>> -min
>>
>> So unit tests (IMO) should not need external resources to run, should
>>be very fast, etc as Sudha has indicated.
>>
>> If you need DB access, that sounds much more like a
>>functional/integration test to my ears.
>>
>> --David
>>
Re: [DISCUSS]How to write API Unit Tests
Posted by Chip Childers <ch...@sungard.com>.
+1 to what everyone is saying. This sounds like a functional test is
needed, along with a simple unit test for completeness.
- chip
Sent from my iPhone.
On Nov 27, 2012, at 8:33 PM, Sudha Ponnaganti
<su...@citrix.com> wrote:
> Min,
>
> Here is the link to the current framework
> https://cwiki.apache.org/CLOUDSTACK/testing-with-python.html
>
> Also check out Rohit's CLI as well. That would also help to automate faster
>
> Thanks
> /Sudha
>
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Tuesday, November 27, 2012 5:28 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS]How to write API Unit Tests
>
> On Tue, Nov 27, 2012 at 6:09 PM, Min Chen <mi...@citrix.com> wrote:
>> Hi there,
>>
>> In working with API refactoring work, I cannot help wondering
>> how we should write Junit test cases for our APIs. Recently I saw that
>> Chip has merged some of his API unit test cases into master branch,
>> and his api unit test cases are written using Mockito, so no DB and
>> real MS are needed in running these Junit test cases. Here I want to
>> raise this topic again to get some clarifications on api unit test guidelines:
>> 1. Should we require API unit test cases to be able to run
>> without DB existing or MS running?
>> 2. If answer is yes, then I guess that we just need to use
>> Mockito to write our api unit test cases.
>> 3. If answer is no, there are several follow-up questions to be clarified:
>> 1) Does test case itself need to handle starting MS and stopping MS?
>> 2) How should we set up a test DB? This may be needed for
>> those list APIs.
>> 3) Testcases need to handle tear down test data afterwards.
>>
>> Thanks
>> -min
>
> So unit tests (IMO) should not need external resources to run, should be very fast, etc as Sudha has indicated.
>
> If you need DB access, that sounds much more like a functional/integration test to my ears.
>
> --David
>
RE: [DISCUSS]How to write API Unit Tests
Posted by Sudha Ponnaganti <su...@citrix.com>.
Min,
Here is the link to the current framework
https://cwiki.apache.org/CLOUDSTACK/testing-with-python.html
Also check out Rohit's CLI as well. That would also help to automate faster
Thanks
/Sudha
-----Original Message-----
From: David Nalley [mailto:david@gnsa.us]
Sent: Tuesday, November 27, 2012 5:28 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS]How to write API Unit Tests
On Tue, Nov 27, 2012 at 6:09 PM, Min Chen <mi...@citrix.com> wrote:
> Hi there,
>
> In working with API refactoring work, I cannot help wondering
> how we should write Junit test cases for our APIs. Recently I saw that
> Chip has merged some of his API unit test cases into master branch,
> and his api unit test cases are written using Mockito, so no DB and
> real MS are needed in running these Junit test cases. Here I want to
> raise this topic again to get some clarifications on api unit test guidelines:
> 1. Should we require API unit test cases to be able to run
> without DB existing or MS running?
> 2. If answer is yes, then I guess that we just need to use
> Mockito to write our api unit test cases.
> 3. If answer is no, there are several follow-up questions to be clarified:
> 1) Does test case itself need to handle starting MS and stopping MS?
> 2) How should we set up a test DB? This may be needed for
> those list APIs.
> 3) Testcases need to handle tear down test data afterwards.
>
> Thanks
> -min
>
So unit tests (IMO) should not need external resources to run, should be very fast, etc as Sudha has indicated.
If you need DB access, that sounds much more like a functional/integration test to my ears.
--David
Re: [DISCUSS]How to write API Unit Tests
Posted by David Nalley <da...@gnsa.us>.
On Tue, Nov 27, 2012 at 6:09 PM, Min Chen <mi...@citrix.com> wrote:
> Hi there,
>
> In working with API refactoring work, I cannot help wondering how we
> should write Junit test cases for our APIs. Recently I saw that Chip has
> merged some of his API unit test cases into master branch, and his api
> unit test cases are written using Mockito, so no DB and real MS are needed
> in running these Junit test cases. Here I want to raise this topic again
> to get some clarifications on api unit test guidelines:
> 1. Should we require API unit test cases to be able to run without DB
> existing or MS running?
> 2. If answer is yes, then I guess that we just need to use Mockito to
> write our api unit test cases.
> 3. If answer is no, there are several follow-up questions to be clarified:
> 1) Does test case itself need to handle starting MS and stopping MS?
> 2) How should we set up a test DB? This may be needed for those list
> APIs.
> 3) Testcases need to handle tear down test data afterwards.
>
> Thanks
> -min
>
So unit tests (IMO) should not need external resources to run, should
be very fast, etc as Sudha has indicated.
If you need DB access, that sounds much more like a
functional/integration test to my ears.
--David
Re: [DISCUSS]How to write API Unit Tests
Posted by Min Chen <mi...@citrix.com>.
Where is functional suite code located in our code base? How does our
current functional suite currently handle populating data to DB?
Thanks
-min
On 11/27/12 5:22 PM, "Sudha Ponnaganti" <su...@citrix.com>
wrote:
>Min,
>
>Does it make sense to add test cases to functional suite?? We have
>extensive suite running now and it would help if you need to test DB and
>functional aspects of APIs rather than testing code.
>
>Thanks
>/Sudha
>
>-----Original Message-----
>From: Min Chen [mailto:min.chen@citrix.com]
>Sent: Tuesday, November 27, 2012 5:17 PM
>To: cloudstack-dev@incubator.apache.org
>Subject: Re: [DISCUSS]How to write API Unit Tests
>
>The idea of not dependent on DB is nice, but I am not sure if this will
>apply well to this particular LIST api performance refactor code I am
>working on. In this case, the idea is to create Database view to remove
>extra db trips in response generation to get various uuids. Without
>talking to Database, feel that it is not testing the new code at all. And
>by mocking all those manager classes (e.g. UserVmManagerImpl, etc), the
>code path our api unit test case can cover will be only limited to that
>one execute method in each api Command class. With such unit test cases,
>I am afraid that we cannot be confident enough to say yes for the simple
>question: Do the results returned by the api calls before and after the
>changes are exactly same or not?
>
>Thanks
>-min
>
>On 11/27/12 3:43 PM, "Animesh Chaturvedi" <an...@citrix.com>
>wrote:
>
>>Min
>>
>>I have few comments in-line.
>>
>>-----Original Message-----
>>From: Min Chen [mailto:min.chen@citrix.com]
>>Sent: Tuesday, November 27, 2012 3:10 PM
>>To: cloudstack-dev@incubator.apache.org
>>Subject: [DISCUSS]How to write API Unit Tests
>>
>>Hi there,
>>
>> In working with API refactoring work, I cannot help wondering how we
>>should write Junit test cases for our APIs. Recently I saw that Chip
>>has merged some of his API unit test cases into master branch, and his
>>api unit test cases are written using Mockito, so no DB and real MS are
>>needed in running these Junit test cases. Here I want to raise this
>>topic again to get some clarifications on api unit test guidelines:
>> 1. Should we require API unit test cases to be able to run without DB
>>existing or MS running?
>>Animesh> Unit tests are meant to be run quickly and test only small
>>portion of software independent of other things. In my opinion unit
>>tests should not talk to database, communicate across network, require
>>special environment changes like editing config files etc.
>> 2. If answer is yes, then I guess that we just need to use Mockito to
>>write our api unit test cases.
>>Animesh> Yes using mock objects should be the way to go. Here is a
>>classic paper on Unit testing with Mock Objects
>>http://www.betgenius.com/mockobjects.pdf .
>>
>> 3. If answer is no, there are several follow-up questions to be
>>clarified:
>> 1) Does test case itself need to handle starting MS and stopping MS?
>> 2) How should we set up a test DB? This may be needed for those
>>list APIs.
>> 3) Testcases need to handle tear down test data afterwards.
>>
>> Thanks
>> -min
>>
>
RE: [DISCUSS]How to write API Unit Tests
Posted by Sudha Ponnaganti <su...@citrix.com>.
Min,
Does it make sense to add test cases to functional suite?? We have extensive suite running now and it would help if you need to test DB and functional aspects of APIs rather than testing code.
Thanks
/Sudha
-----Original Message-----
From: Min Chen [mailto:min.chen@citrix.com]
Sent: Tuesday, November 27, 2012 5:17 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS]How to write API Unit Tests
The idea of not dependent on DB is nice, but I am not sure if this will apply well to this particular LIST api performance refactor code I am working on. In this case, the idea is to create Database view to remove extra db trips in response generation to get various uuids. Without talking to Database, feel that it is not testing the new code at all. And by mocking all those manager classes (e.g. UserVmManagerImpl, etc), the code path our api unit test case can cover will be only limited to that one execute method in each api Command class. With such unit test cases, I am afraid that we cannot be confident enough to say yes for the simple
question: Do the results returned by the api calls before and after the changes are exactly same or not?
Thanks
-min
On 11/27/12 3:43 PM, "Animesh Chaturvedi" <an...@citrix.com>
wrote:
>Min
>
>I have few comments in-line.
>
>-----Original Message-----
>From: Min Chen [mailto:min.chen@citrix.com]
>Sent: Tuesday, November 27, 2012 3:10 PM
>To: cloudstack-dev@incubator.apache.org
>Subject: [DISCUSS]How to write API Unit Tests
>
>Hi there,
>
> In working with API refactoring work, I cannot help wondering how we
>should write Junit test cases for our APIs. Recently I saw that Chip
>has merged some of his API unit test cases into master branch, and his
>api unit test cases are written using Mockito, so no DB and real MS are
>needed in running these Junit test cases. Here I want to raise this
>topic again to get some clarifications on api unit test guidelines:
> 1. Should we require API unit test cases to be able to run without DB
>existing or MS running?
>Animesh> Unit tests are meant to be run quickly and test only small
>portion of software independent of other things. In my opinion unit
>tests should not talk to database, communicate across network, require
>special environment changes like editing config files etc.
> 2. If answer is yes, then I guess that we just need to use Mockito to
>write our api unit test cases.
>Animesh> Yes using mock objects should be the way to go. Here is a
>classic paper on Unit testing with Mock Objects
>http://www.betgenius.com/mockobjects.pdf .
>
> 3. If answer is no, there are several follow-up questions to be
>clarified:
> 1) Does test case itself need to handle starting MS and stopping MS?
> 2) How should we set up a test DB? This may be needed for those
>list APIs.
> 3) Testcases need to handle tear down test data afterwards.
>
> Thanks
> -min
>
RE: [DISCUSS]How to write API Unit Tests
Posted by Animesh Chaturvedi <an...@citrix.com>.
Min
Agree that your API testing needs DB and is blurring towards functional testing. If you need to lot of database-driven testing you may consider evaluating DBUnit http://www.dbunit.org/howto.html
Thanks
Animesh
-----Original Message-----
From: Min Chen [mailto:min.chen@citrix.com]
Sent: Tuesday, November 27, 2012 5:17 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS]How to write API Unit Tests
The idea of not dependent on DB is nice, but I am not sure if this will apply well to this particular LIST api performance refactor code I am working on. In this case, the idea is to create Database view to remove extra db trips in response generation to get various uuids. Without talking to Database, feel that it is not testing the new code at all. And by mocking all those manager classes (e.g. UserVmManagerImpl, etc), the code path our api unit test case can cover will be only limited to that one execute method in each api Command class. With such unit test cases, I am afraid that we cannot be confident enough to say yes for the simple
question: Do the results returned by the api calls before and after the changes are exactly same or not?
Thanks
-min
On 11/27/12 3:43 PM, "Animesh Chaturvedi" <an...@citrix.com>
wrote:
>Min
>
>I have few comments in-line.
>
>-----Original Message-----
>From: Min Chen [mailto:min.chen@citrix.com]
>Sent: Tuesday, November 27, 2012 3:10 PM
>To: cloudstack-dev@incubator.apache.org
>Subject: [DISCUSS]How to write API Unit Tests
>
>Hi there,
>
> In working with API refactoring work, I cannot help wondering how we
>should write Junit test cases for our APIs. Recently I saw that Chip
>has merged some of his API unit test cases into master branch, and his
>api unit test cases are written using Mockito, so no DB and real MS are
>needed in running these Junit test cases. Here I want to raise this
>topic again to get some clarifications on api unit test guidelines:
> 1. Should we require API unit test cases to be able to run without DB
>existing or MS running?
>Animesh> Unit tests are meant to be run quickly and test only small
>portion of software independent of other things. In my opinion unit
>tests should not talk to database, communicate across network, require
>special environment changes like editing config files etc.
> 2. If answer is yes, then I guess that we just need to use Mockito to
>write our api unit test cases.
>Animesh> Yes using mock objects should be the way to go. Here is a
>classic paper on Unit testing with Mock Objects
>http://www.betgenius.com/mockobjects.pdf .
>
> 3. If answer is no, there are several follow-up questions to be
>clarified:
> 1) Does test case itself need to handle starting MS and stopping MS?
> 2) How should we set up a test DB? This may be needed for those
>list APIs.
> 3) Testcases need to handle tear down test data afterwards.
>
> Thanks
> -min
>
Re: [DISCUSS]How to write API Unit Tests
Posted by Min Chen <mi...@citrix.com>.
The idea of not dependent on DB is nice, but I am not sure if this will
apply well to this particular LIST api performance refactor code I am
working on. In this case, the idea is to create Database view to remove
extra db trips in response generation to get various uuids. Without
talking to Database, feel that it is not testing the new code at all. And
by mocking all those manager classes (e.g. UserVmManagerImpl, etc), the
code path our api unit test case can cover will be only limited to that
one execute method in each api Command class. With such unit test cases, I
am afraid that we cannot be confident enough to say yes for the simple
question: Do the results returned by the api calls before and after the
changes are exactly same or not?
Thanks
-min
On 11/27/12 3:43 PM, "Animesh Chaturvedi" <an...@citrix.com>
wrote:
>Min
>
>I have few comments in-line.
>
>-----Original Message-----
>From: Min Chen [mailto:min.chen@citrix.com]
>Sent: Tuesday, November 27, 2012 3:10 PM
>To: cloudstack-dev@incubator.apache.org
>Subject: [DISCUSS]How to write API Unit Tests
>
>Hi there,
>
> In working with API refactoring work, I cannot help wondering how we
>should write Junit test cases for our APIs. Recently I saw that Chip has
>merged some of his API unit test cases into master branch, and his api
>unit test cases are written using Mockito, so no DB and real MS are
>needed in running these Junit test cases. Here I want to raise this topic
>again to get some clarifications on api unit test guidelines:
> 1. Should we require API unit test cases to be able to run without DB
>existing or MS running?
>Animesh> Unit tests are meant to be run quickly and test only small
>portion of software independent of other things. In my opinion unit tests
>should not talk to database, communicate across network, require special
>environment changes like editing config files etc.
> 2. If answer is yes, then I guess that we just need to use Mockito to
>write our api unit test cases.
>Animesh> Yes using mock objects should be the way to go. Here is a
>classic paper on Unit testing with Mock Objects
>http://www.betgenius.com/mockobjects.pdf .
>
> 3. If answer is no, there are several follow-up questions to be
>clarified:
> 1) Does test case itself need to handle starting MS and stopping MS?
> 2) How should we set up a test DB? This may be needed for those list
>APIs.
> 3) Testcases need to handle tear down test data afterwards.
>
> Thanks
> -min
>
RE: [DISCUSS]How to write API Unit Tests
Posted by Animesh Chaturvedi <an...@citrix.com>.
Min
I have few comments in-line.
-----Original Message-----
From: Min Chen [mailto:min.chen@citrix.com]
Sent: Tuesday, November 27, 2012 3:10 PM
To: cloudstack-dev@incubator.apache.org
Subject: [DISCUSS]How to write API Unit Tests
Hi there,
In working with API refactoring work, I cannot help wondering how we should write Junit test cases for our APIs. Recently I saw that Chip has merged some of his API unit test cases into master branch, and his api unit test cases are written using Mockito, so no DB and real MS are needed in running these Junit test cases. Here I want to raise this topic again to get some clarifications on api unit test guidelines:
1. Should we require API unit test cases to be able to run without DB existing or MS running?
Animesh> Unit tests are meant to be run quickly and test only small portion of software independent of other things. In my opinion unit tests should not talk to database, communicate across network, require special environment changes like editing config files etc.
2. If answer is yes, then I guess that we just need to use Mockito to write our api unit test cases.
Animesh> Yes using mock objects should be the way to go. Here is a classic paper on Unit testing with Mock Objects http://www.betgenius.com/mockobjects.pdf .
3. If answer is no, there are several follow-up questions to be clarified:
1) Does test case itself need to handle starting MS and stopping MS?
2) How should we set up a test DB? This may be needed for those list APIs.
3) Testcases need to handle tear down test data afterwards.
Thanks
-min
Re: Unit tests
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Nov 9, 2012 at 3:24 PM, Alex Huang <Al...@citrix.com> wrote:
>
>
>> -----Original Message-----
>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>> Sent: Friday, November 09, 2012 12:19 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: RE: Unit tests
>>
>> > >> 2 - Do we want to get stricter about what exactly is considered to be
>> > >> a unit test (vs an automated test that may or may not be based on the
>> > >> junit framework)?
>> > >
>> > > I actually consider db tests to be unit tests as long as the db is setup and
>> > cleaned up by the unit test itself.
>> >
>> > Having a real DB as a requirement for low level unit tests does two
>> > things that I don't like.
>> >
>> > First, it requires the configuration of a database (in our case,
>> > MySQL) as part of running the test. That's a build dependency that
>> > (IMO) shouldn't be needed.
>> >
>> > Second, configuring and using a real database significantly slows down
>> > the unit test process. For unit tests to be useful, they have to be
>> > as fast as possible. We simply don't have enough unit tests for this
>> > to be a major problem right now, but as the coverage increases (true
>> > unit tests, not integration tests) this will get much worse.
>> >
>> > In my ideal world, unit tests are limited in their test scope to only
>> > cover code within a particular object (inherited or directly
>> > accessed). Imported objects should usually be mocked. We might be
>> > arguing about nuance of definition here, but I've always tried to keep
>> > a bright red line between unit and integration tests. Both matter,
>> > but they test different things.
>> >
>>
>> Actually, you and I are not that far apart. I'm thinking mainly in terms of
>> testing code that are actually accessing database. For example, the unit test
>> is to ensure a search query returns the results that are intended. You can't
>> really mock those up.
>>
>> For code paths that are not testing search queries but are just dependent on
>> search results, I agree with you. Just mock up the DAOs.
>
> And as for it being slow, perhaps we can split unit tests into two levels. One level is for testing access to db and one level is for actual business logic.
>
> --Alex
>
I think that's the right answer. If we can have them broken out as
functional tests, which are run by the CI server or a developer that
wants to run them on demand, then that would be best. If the unit
tests are in the compile path, and are fast, then we always know that
each build will force a unit test run. That really requires the
separation of unit from functional.
Re: Unit tests
Posted by Satoshi Kobayashi <sa...@stratosphere.co.jp>.
2012/11/10 Sudha Ponnaganti <su...@citrix.com>:
> Can any tests that require external components be added to the functional regressions that are enabled now? This way you can keep unit and functional tests clearly separated.
+1
IMHO, An automation test separate and should be considered.
For example and tendency
Unit testing:
- It runs when built
- It does not use an external component
- Low layer, fast
Functional testing:
- It does not run when built
- It uses an external component
- High layer, maybe slow
>
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Friday, November 09, 2012 12:24 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Unit tests
>
>
>
>> -----Original Message-----
>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>> Sent: Friday, November 09, 2012 12:19 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: RE: Unit tests
>>
>> > >> 2 - Do we want to get stricter about what exactly is considered
>> > >> to be a unit test (vs an automated test that may or may not be
>> > >> based on the junit framework)?
>> > >
>> > > I actually consider db tests to be unit tests as long as the db is
>> > > setup and
>> > cleaned up by the unit test itself.
>> >
>> > Having a real DB as a requirement for low level unit tests does two
>> > things that I don't like.
>> >
>> > First, it requires the configuration of a database (in our case,
>> > MySQL) as part of running the test. That's a build dependency that
>> > (IMO) shouldn't be needed.
>> >
>> > Second, configuring and using a real database significantly slows
>> > down the unit test process. For unit tests to be useful, they have
>> > to be as fast as possible. We simply don't have enough unit tests
>> > for this to be a major problem right now, but as the coverage
>> > increases (true unit tests, not integration tests) this will get much worse.
>> >
>> > In my ideal world, unit tests are limited in their test scope to
>> > only cover code within a particular object (inherited or directly
>> > accessed). Imported objects should usually be mocked. We might be
>> > arguing about nuance of definition here, but I've always tried to
>> > keep a bright red line between unit and integration tests. Both
>> > matter, but they test different things.
>> >
>>
>> Actually, you and I are not that far apart. I'm thinking mainly in
>> terms of testing code that are actually accessing database. For
>> example, the unit test is to ensure a search query returns the results
>> that are intended. You can't really mock those up.
>>
>> For code paths that are not testing search queries but are just
>> dependent on search results, I agree with you. Just mock up the DAOs.
>
> And as for it being slow, perhaps we can split unit tests into two levels. One level is for testing access to db and one level is for actual business logic.
>
> --Alex
--
Satoshi Kobayashi <sa...@stratosphere.co.jp>
RE: Unit tests
Posted by Sudha Ponnaganti <su...@citrix.com>.
Can any tests that require external components be added to the functional regressions that are enabled now? This way you can keep unit and functional tests clearly separated.
-----Original Message-----
From: Alex Huang [mailto:Alex.Huang@citrix.com]
Sent: Friday, November 09, 2012 12:24 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: Unit tests
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Friday, November 09, 2012 12:19 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Unit tests
>
> > >> 2 - Do we want to get stricter about what exactly is considered
> > >> to be a unit test (vs an automated test that may or may not be
> > >> based on the junit framework)?
> > >
> > > I actually consider db tests to be unit tests as long as the db is
> > > setup and
> > cleaned up by the unit test itself.
> >
> > Having a real DB as a requirement for low level unit tests does two
> > things that I don't like.
> >
> > First, it requires the configuration of a database (in our case,
> > MySQL) as part of running the test. That's a build dependency that
> > (IMO) shouldn't be needed.
> >
> > Second, configuring and using a real database significantly slows
> > down the unit test process. For unit tests to be useful, they have
> > to be as fast as possible. We simply don't have enough unit tests
> > for this to be a major problem right now, but as the coverage
> > increases (true unit tests, not integration tests) this will get much worse.
> >
> > In my ideal world, unit tests are limited in their test scope to
> > only cover code within a particular object (inherited or directly
> > accessed). Imported objects should usually be mocked. We might be
> > arguing about nuance of definition here, but I've always tried to
> > keep a bright red line between unit and integration tests. Both
> > matter, but they test different things.
> >
>
> Actually, you and I are not that far apart. I'm thinking mainly in
> terms of testing code that are actually accessing database. For
> example, the unit test is to ensure a search query returns the results
> that are intended. You can't really mock those up.
>
> For code paths that are not testing search queries but are just
> dependent on search results, I agree with you. Just mock up the DAOs.
And as for it being slow, perhaps we can split unit tests into two levels. One level is for testing access to db and one level is for actual business logic.
--Alex
RE: Unit tests
Posted by Alex Huang <Al...@citrix.com>.
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Friday, November 09, 2012 12:19 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Unit tests
>
> > >> 2 - Do we want to get stricter about what exactly is considered to be
> > >> a unit test (vs an automated test that may or may not be based on the
> > >> junit framework)?
> > >
> > > I actually consider db tests to be unit tests as long as the db is setup and
> > cleaned up by the unit test itself.
> >
> > Having a real DB as a requirement for low level unit tests does two
> > things that I don't like.
> >
> > First, it requires the configuration of a database (in our case,
> > MySQL) as part of running the test. That's a build dependency that
> > (IMO) shouldn't be needed.
> >
> > Second, configuring and using a real database significantly slows down
> > the unit test process. For unit tests to be useful, they have to be
> > as fast as possible. We simply don't have enough unit tests for this
> > to be a major problem right now, but as the coverage increases (true
> > unit tests, not integration tests) this will get much worse.
> >
> > In my ideal world, unit tests are limited in their test scope to only
> > cover code within a particular object (inherited or directly
> > accessed). Imported objects should usually be mocked. We might be
> > arguing about nuance of definition here, but I've always tried to keep
> > a bright red line between unit and integration tests. Both matter,
> > but they test different things.
> >
>
> Actually, you and I are not that far apart. I'm thinking mainly in terms of
> testing code that are actually accessing database. For example, the unit test
> is to ensure a search query returns the results that are intended. You can't
> really mock those up.
>
> For code paths that are not testing search queries but are just dependent on
> search results, I agree with you. Just mock up the DAOs.
And as for it being slow, perhaps we can split unit tests into two levels. One level is for testing access to db and one level is for actual business logic.
--Alex
RE: Unit tests
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Friday, November 09, 2012 9:19 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Unit tests
>
> > >> 2 - Do we want to get stricter about what exactly is considered to
> > >> be a unit test (vs an automated test that may or may not be based
> > >> on the junit framework)?
> > >
> > > I actually consider db tests to be unit tests as long as the db is
> > > setup and
> > cleaned up by the unit test itself.
> >
> > Having a real DB as a requirement for low level unit tests does two
> > things that I don't like.
> >
> > First, it requires the configuration of a database (in our case,
> > MySQL) as part of running the test. That's a build dependency that
> > (IMO) shouldn't be needed.
> >
> > Second, configuring and using a real database significantly slows down
> > the unit test process. For unit tests to be useful, they have to be
> > as fast as possible. We simply don't have enough unit tests for this
> > to be a major problem right now, but as the coverage increases (true
> > unit tests, not integration tests) this will get much worse.
> >
> > In my ideal world, unit tests are limited in their test scope to only
> > cover code within a particular object (inherited or directly
> > accessed). Imported objects should usually be mocked. We might be
> > arguing about nuance of definition here, but I've always tried to keep
> > a bright red line between unit and integration tests. Both matter,
> > but they test different things.
> >
>
> Actually, you and I are not that far apart. I'm thinking mainly in terms of
> testing code that are actually accessing database. For example, the unit test
> is to ensure a search query returns the results that are intended. You can't
> really mock those up.
This depends on the point of view. We don't need to test if the database is actually returning the right answers. I trust the mysql guys to take care of this part. In this example the unites could be to see if the SearchBuilder contains the correct parameters based on the objects we passed into it, as the SearchBuilder is something that we should check. Maybe even check if the resulting query is as expected and the correct parameter set. This is more work than just sending the query to the database, but provides more fine grained details on the unittests. If you use the database, you are not only testing the unit being tested but also the database, the procedure used to setup the database and any previous steps done using that database. In which case a failure of the unittest will not even tell you where the failure occurred, it could be in any of the mentioned components, which in my view defeats part of the purpose of a unittest, which is the ability to directly pinpoint a class with a failure.
Hugo
>
> For code paths that are not testing search queries but are just dependent on
> search results, I agree with you. Just mock up the DAOs.
>
> --Alex
RE: Unit tests
Posted by Alex Huang <Al...@citrix.com>.
> >> 2 - Do we want to get stricter about what exactly is considered to be
> >> a unit test (vs an automated test that may or may not be based on the
> >> junit framework)?
> >
> > I actually consider db tests to be unit tests as long as the db is setup and
> cleaned up by the unit test itself.
>
> Having a real DB as a requirement for low level unit tests does two
> things that I don't like.
>
> First, it requires the configuration of a database (in our case,
> MySQL) as part of running the test. That's a build dependency that
> (IMO) shouldn't be needed.
>
> Second, configuring and using a real database significantly slows down
> the unit test process. For unit tests to be useful, they have to be
> as fast as possible. We simply don't have enough unit tests for this
> to be a major problem right now, but as the coverage increases (true
> unit tests, not integration tests) this will get much worse.
>
> In my ideal world, unit tests are limited in their test scope to only
> cover code within a particular object (inherited or directly
> accessed). Imported objects should usually be mocked. We might be
> arguing about nuance of definition here, but I've always tried to keep
> a bright red line between unit and integration tests. Both matter,
> but they test different things.
>
Actually, you and I are not that far apart. I'm thinking mainly in terms of testing code that are actually accessing database. For example, the unit test is to ensure a search query returns the results that are intended. You can't really mock those up.
For code paths that are not testing search queries but are just dependent on search results, I agree with you. Just mock up the DAOs.
--Alex
Re: Unit tests
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Nov 9, 2012 at 2:46 PM, Alex Huang <Al...@citrix.com> wrote:
>>
>> 1 - Do we want tests to run each time mvn install is run?
>
> No. I like to have choices.
>
>>
>> 2 - Do we want to get stricter about what exactly is considered to be
>> a unit test (vs an automated test that may or may not be based on the
>> junit framework)?
>
> I actually consider db tests to be unit tests as long as the db is setup and cleaned up by the unit test itself.
Having a real DB as a requirement for low level unit tests does two
things that I don't like.
First, it requires the configuration of a database (in our case,
MySQL) as part of running the test. That's a build dependency that
(IMO) shouldn't be needed.
Second, configuring and using a real database significantly slows down
the unit test process. For unit tests to be useful, they have to be
as fast as possible. We simply don't have enough unit tests for this
to be a major problem right now, but as the coverage increases (true
unit tests, not integration tests) this will get much worse.
In my ideal world, unit tests are limited in their test scope to only
cover code within a particular object (inherited or directly
accessed). Imported objects should usually be mocked. We might be
arguing about nuance of definition here, but I've always tried to keep
a bright red line between unit and integration tests. Both matter,
but they test different things.
> I think anything that requires starting of jetty is definitely not a unit test.
Completely agree with this one.
> --Alex
>
RE: Unit tests
Posted by Alex Huang <Al...@citrix.com>.
>
> 1 - Do we want tests to run each time mvn install is run?
No. I like to have choices.
>
> 2 - Do we want to get stricter about what exactly is considered to be
> a unit test (vs an automated test that may or may not be based on the
> junit framework)?
I actually consider db tests to be unit tests as long as the db is setup and cleaned up by the unit test itself.
I think anything that requires starting of jetty is definitely not a unit test.
--Alex
Re: Unit tests
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Nov 9, 2012 at 2:30 PM, Alex Huang <Al...@citrix.com> wrote:
> +1 the more tests the merrier.
>
> I have noticed that in master doing mvn install actually runs some unit tests. I don't like that because it slows down compilation. I haven't track down exactly what it is but I think it's in the nicira plugin.
I think tests are running for everything, and some of them are not
actually unit tests. Anything that requires something like a DB isn't
a true unit test IMO. I think there are 2 questions to answer here:
1 - Do we want tests to run each time mvn install is run?
2 - Do we want to get stricter about what exactly is considered to be
a unit test (vs an automated test that may or may not be based on the
junit framework)?
> --Alex
>
>> -----Original Message-----
>> From: Chip Childers [mailto:chip.childers@sungard.com]
>> Sent: Friday, November 09, 2012 11:21 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: Unit tests
>>
>> I'd like to drop this branch (after moving completed tests over to
>> master). The reason that I created it was to specifically avoid
>> messing up the 4.0 work. Since we've moved on already, any issues
>> integrating the new tests into master?
>>
>> -chip
>>
>> On Tue, Oct 30, 2012 at 3:34 PM, Matthew Morrissey
>> <ma...@sungard.com> wrote:
>> > I would be working on everything in api/src/com/cloud/api/
>> >
>> > On Tue, Oct 30, 2012 at 1:52 PM, Manikanta Kattamuri <
>> > manikanta.kattamuri@sungard.com> wrote:
>> >
>> >> Hi All,
>> >>
>> >> Chip has created a branch for junit-tests.
>> >> There are some issues with folder structure in it, I sent a patch for
>> >> review 7776 on request board, once it is reviewed and committed the
>> >> structure will be set and all the units already written are in the new
>> >> structure.
>> >>
>> >> Mani
>> >>
>> >> -----Original Message-----
>> >> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>> >> Sent: Tuesday, October 30, 2012 9:31 PM
>> >> To: cloudstack-dev@incubator.apache.org
>> >> Subject: RE: Unit tests
>> >>
>> >> Matthew,
>> >>
>> >> Are you looking to write unit tests for which set of APIs? Is it the
>> >> management server APIs, plugin APIs, or resource APIs?
>> >>
>> >> Yup. Hugo's path is the correct one.
>> >>
>> >> --Alex
>> >>
>> >> > -----Original Message-----
>> >> > From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
>> >> > Sent: Tuesday, October 30, 2012 8:02 AM
>> >> > To: cloudstack-dev@incubator.apache.org
>> >> > Subject: RE: Unit tests
>> >> >
>> >> > Hey Matthew,
>> >> >
>> >> > Go go go !
>> >> >
>> >> > Put please put the tests in <sub_project_folder>/test/com/cloud/....
>> >> > That would keep it compatible with the existing location for unit
>> >> > tests and make it work with maven right away :-)
>> >> >
>> >> > Cheers,
>> >> >
>> >> > HUgo
>> >> >
>> >> > > -----Original Message-----
>> >> > > From: Matthew Morrissey [mailto:matthew.morrissey@sungard.com]
>> >> > > Sent: Tuesday, October 30, 2012 3:35 PM
>> >> > > To: cloudstack-dev@incubator.apache.org
>> >> > > Subject: Unit tests
>> >> > >
>> >> > > Hello all,
>> >> > >
>> >> > > I would like to begin writing unit tests for api/src/com/cloud/api
>> >> > > and I wanted to make sure that 1) it's an acceptable idea to
>> >> > > everyone and
>> >> > > 2) I get the directory structure correct. I have seen a few emails
>> >> > > about the possible structure but no concrete "this is the way to go"
>> >> > > type
>> >> > statements.
>> >> > > My thought is that these tests would be in
>> >> > > api/src/test/java/com/cloud/api/*.java. Is this the right line of
>> >> thought?
>> >> > > Please let me know and I'll get the ball rolling. I've got a long
>> >> > > way to go if I want to catch up to Yichi :)
>> >> > >
>> >> > > --
>> >> > > Matthew Morrissey
>> >> > > Software Engineer - SunGard Availability Services - 401 N. Broad
>> >> > > Street, Philadelphia, PA 19108
>> >> > > o: 215-446-2713 - e: matthew.morrissey@sungard.com
>> >>
>> >>
>> >
>> >
>> > --
>> > Matthew Morrissey
>> > Software Engineer I - SunGard Availability Services - 401 N. Broad Street,
>> > Philadelphia, PA 19108
>> > o: 215-446-2713 - e: matthew.morrissey@sungard.com
>
Re: Unit tests
Posted by prasanna <ts...@apache.org>.
On 10 November 2012 03:03, David Nalley <da...@gnsa.us> wrote:
> On Fri, Nov 9, 2012 at 2:30 PM, Alex Huang <Al...@citrix.com> wrote:
>> +1 the more tests the merrier.
>>
>> I have noticed that in master doing mvn install actually runs some unit tests. I don't like that because it slows down compilation. I haven't track down exactly what it is but I think it's in the nicira plugin.
>>
>
> IMO (which isn't worth very much) running unit tests at compile is a
> good thing. It puts unit tests failures front and center to anyone
> working on the code and gets back to that idea of everyone being
> responsible for code quality. If a unit test is failing we have no
> business doing anything else until that is fixed. Currently these
> tests are only adding a few seconds to compile time in my limited
> tests. Additionally, if folks get into the habit of not running the
> tests on every compile they will never run the tests, and a failure
> will only come to light when jenkins runs the tests post-commit.
>
> If you really must not run the tests, you can always run -DskipTests=true
The current unittests are great to have. If we don't run them I feel
they will get abandoned later like it has happened before with
CloudStack. Many of the tests had to be resurrected to work against
the refactoring and changing of the build system for 4.0. Also, with
javelin work breaking down components it should not be hard to run
tests for the components that one affects/changes and not the entire
suite.
Re: Unit tests
Posted by prasanna <sr...@gmail.com>.
On 10 November 2012 03:03, David Nalley <da...@gnsa.us> wrote:
> On Fri, Nov 9, 2012 at 2:30 PM, Alex Huang <Al...@citrix.com> wrote:
>> +1 the more tests the merrier.
>>
>> I have noticed that in master doing mvn install actually runs some unit tests. I don't like that because it slows down compilation. I haven't track down exactly what it is but I think it's in the nicira plugin.
>>
>
> IMO (which isn't worth very much) running unit tests at compile is a
> good thing. It puts unit tests failures front and center to anyone
> working on the code and gets back to that idea of everyone being
> responsible for code quality. If a unit test is failing we have no
> business doing anything else until that is fixed. Currently these
> tests are only adding a few seconds to compile time in my limited
> tests. Additionally, if folks get into the habit of not running the
> tests on every compile they will never run the tests, and a failure
> will only come to light when jenkins runs the tests post-commit.
>
> If you really must not run the tests, you can always run -DskipTests=true
>
> --David
The current unittests are great to have. If we don't run them I feel
they will get abandoned later like it has happened before with
CloudStack. Many of the tests had to be resurrected to work against
the refactoring and changing of the build system for 4.0. Also, with
javelin work breaking down components it should not be hard to run
tests for the components that one affects/changes and not the entire
suite.
--
Prasanna.,
RE: Unit tests
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Friday, November 09, 2012 10:34 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Unit tests
>
> On Fri, Nov 9, 2012 at 2:30 PM, Alex Huang <Al...@citrix.com> wrote:
> > +1 the more tests the merrier.
> >
> > I have noticed that in master doing mvn install actually runs some unit
> tests. I don't like that because it slows down compilation. I haven't track
> down exactly what it is but I think it's in the nicira plugin.
> >
>
> IMO (which isn't worth very much) running unit tests at compile is a good
> thing. It puts unit tests failures front and center to anyone working on the
> code and gets back to that idea of everyone being responsible for code
> quality. If a unit test is failing we have no business doing anything else until
> that is fixed. Currently these tests are only adding a few seconds to compile
> time in my limited tests. Additionally, if folks get into the habit of not
> running the tests on every compile they will never run the tests, and a
> failure will only come to light when jenkins runs the tests post-commit.
>
> If you really must not run the tests, you can always run -DskipTests=true
+1
I agree with David that tests should be run on every compile. Of course this depends a lot on the quality and speed of the tests, currently the tests take to long since we have some database related tests in here that slow down the unit tests. Ideally the tests should just be a few seconds (with is nothing compared to the awsapi compile) and will tell you immediately if one of the changes you are compiling into the code did actually break one of the existing unittests. This would improve the quality of the code that gets committed. (Provided we have a decent coverage)
Maven has a notion of both unittests and integration tests. Though the definition of a unittest varies, the general consensus is that they should not required outside resources and generally be fast enough to run frequently. The integration tests are designed to see if multiple components actually are able to work together. Inherently slower and not run at compile time, but for example right before committing.
Hugo
>
> --David
Re: Unit tests
Posted by David Nalley <da...@gnsa.us>.
On Fri, Nov 9, 2012 at 2:30 PM, Alex Huang <Al...@citrix.com> wrote:
> +1 the more tests the merrier.
>
> I have noticed that in master doing mvn install actually runs some unit tests. I don't like that because it slows down compilation. I haven't track down exactly what it is but I think it's in the nicira plugin.
>
IMO (which isn't worth very much) running unit tests at compile is a
good thing. It puts unit tests failures front and center to anyone
working on the code and gets back to that idea of everyone being
responsible for code quality. If a unit test is failing we have no
business doing anything else until that is fixed. Currently these
tests are only adding a few seconds to compile time in my limited
tests. Additionally, if folks get into the habit of not running the
tests on every compile they will never run the tests, and a failure
will only come to light when jenkins runs the tests post-commit.
If you really must not run the tests, you can always run -DskipTests=true
--David
RE: Unit tests
Posted by Alex Huang <Al...@citrix.com>.
+1 the more tests the merrier.
I have noticed that in master doing mvn install actually runs some unit tests. I don't like that because it slows down compilation. I haven't track down exactly what it is but I think it's in the nicira plugin.
--Alex
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Friday, November 09, 2012 11:21 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Unit tests
>
> I'd like to drop this branch (after moving completed tests over to
> master). The reason that I created it was to specifically avoid
> messing up the 4.0 work. Since we've moved on already, any issues
> integrating the new tests into master?
>
> -chip
>
> On Tue, Oct 30, 2012 at 3:34 PM, Matthew Morrissey
> <ma...@sungard.com> wrote:
> > I would be working on everything in api/src/com/cloud/api/
> >
> > On Tue, Oct 30, 2012 at 1:52 PM, Manikanta Kattamuri <
> > manikanta.kattamuri@sungard.com> wrote:
> >
> >> Hi All,
> >>
> >> Chip has created a branch for junit-tests.
> >> There are some issues with folder structure in it, I sent a patch for
> >> review 7776 on request board, once it is reviewed and committed the
> >> structure will be set and all the units already written are in the new
> >> structure.
> >>
> >> Mani
> >>
> >> -----Original Message-----
> >> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> >> Sent: Tuesday, October 30, 2012 9:31 PM
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: RE: Unit tests
> >>
> >> Matthew,
> >>
> >> Are you looking to write unit tests for which set of APIs? Is it the
> >> management server APIs, plugin APIs, or resource APIs?
> >>
> >> Yup. Hugo's path is the correct one.
> >>
> >> --Alex
> >>
> >> > -----Original Message-----
> >> > From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
> >> > Sent: Tuesday, October 30, 2012 8:02 AM
> >> > To: cloudstack-dev@incubator.apache.org
> >> > Subject: RE: Unit tests
> >> >
> >> > Hey Matthew,
> >> >
> >> > Go go go !
> >> >
> >> > Put please put the tests in <sub_project_folder>/test/com/cloud/....
> >> > That would keep it compatible with the existing location for unit
> >> > tests and make it work with maven right away :-)
> >> >
> >> > Cheers,
> >> >
> >> > HUgo
> >> >
> >> > > -----Original Message-----
> >> > > From: Matthew Morrissey [mailto:matthew.morrissey@sungard.com]
> >> > > Sent: Tuesday, October 30, 2012 3:35 PM
> >> > > To: cloudstack-dev@incubator.apache.org
> >> > > Subject: Unit tests
> >> > >
> >> > > Hello all,
> >> > >
> >> > > I would like to begin writing unit tests for api/src/com/cloud/api
> >> > > and I wanted to make sure that 1) it's an acceptable idea to
> >> > > everyone and
> >> > > 2) I get the directory structure correct. I have seen a few emails
> >> > > about the possible structure but no concrete "this is the way to go"
> >> > > type
> >> > statements.
> >> > > My thought is that these tests would be in
> >> > > api/src/test/java/com/cloud/api/*.java. Is this the right line of
> >> thought?
> >> > > Please let me know and I'll get the ball rolling. I've got a long
> >> > > way to go if I want to catch up to Yichi :)
> >> > >
> >> > > --
> >> > > Matthew Morrissey
> >> > > Software Engineer - SunGard Availability Services - 401 N. Broad
> >> > > Street, Philadelphia, PA 19108
> >> > > o: 215-446-2713 - e: matthew.morrissey@sungard.com
> >>
> >>
> >
> >
> > --
> > Matthew Morrissey
> > Software Engineer I - SunGard Availability Services - 401 N. Broad Street,
> > Philadelphia, PA 19108
> > o: 215-446-2713 - e: matthew.morrissey@sungard.com
Re: Unit tests
Posted by David Nalley <da...@gnsa.us>.
On Fri, Nov 9, 2012 at 2:21 PM, Chip Childers <ch...@sungard.com> wrote:
> I'd like to drop this branch (after moving completed tests over to
> master). The reason that I created it was to specifically avoid
> messing up the 4.0 work. Since we've moved on already, any issues
> integrating the new tests into master?
>
> -chip
>
None that I see - would love to see this merge
Re: Unit tests
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Nov 9, 2012 at 2:21 PM, Chip Childers <ch...@sungard.com> wrote:
> I'd like to drop this branch (after moving completed tests over to
> master). The reason that I created it was to specifically avoid
> messing up the 4.0 work. Since we've moved on already, any issues
> integrating the new tests into master?
I completed the integration today, and deleted the junit-tests branch.
> -chip
>
> On Tue, Oct 30, 2012 at 3:34 PM, Matthew Morrissey
> <ma...@sungard.com> wrote:
>> I would be working on everything in api/src/com/cloud/api/
>>
>> On Tue, Oct 30, 2012 at 1:52 PM, Manikanta Kattamuri <
>> manikanta.kattamuri@sungard.com> wrote:
>>
>>> Hi All,
>>>
>>> Chip has created a branch for junit-tests.
>>> There are some issues with folder structure in it, I sent a patch for
>>> review 7776 on request board, once it is reviewed and committed the
>>> structure will be set and all the units already written are in the new
>>> structure.
>>>
>>> Mani
>>>
>>> -----Original Message-----
>>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>>> Sent: Tuesday, October 30, 2012 9:31 PM
>>> To: cloudstack-dev@incubator.apache.org
>>> Subject: RE: Unit tests
>>>
>>> Matthew,
>>>
>>> Are you looking to write unit tests for which set of APIs? Is it the
>>> management server APIs, plugin APIs, or resource APIs?
>>>
>>> Yup. Hugo's path is the correct one.
>>>
>>> --Alex
>>>
>>> > -----Original Message-----
>>> > From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
>>> > Sent: Tuesday, October 30, 2012 8:02 AM
>>> > To: cloudstack-dev@incubator.apache.org
>>> > Subject: RE: Unit tests
>>> >
>>> > Hey Matthew,
>>> >
>>> > Go go go !
>>> >
>>> > Put please put the tests in <sub_project_folder>/test/com/cloud/....
>>> > That would keep it compatible with the existing location for unit
>>> > tests and make it work with maven right away :-)
>>> >
>>> > Cheers,
>>> >
>>> > HUgo
>>> >
>>> > > -----Original Message-----
>>> > > From: Matthew Morrissey [mailto:matthew.morrissey@sungard.com]
>>> > > Sent: Tuesday, October 30, 2012 3:35 PM
>>> > > To: cloudstack-dev@incubator.apache.org
>>> > > Subject: Unit tests
>>> > >
>>> > > Hello all,
>>> > >
>>> > > I would like to begin writing unit tests for api/src/com/cloud/api
>>> > > and I wanted to make sure that 1) it's an acceptable idea to
>>> > > everyone and
>>> > > 2) I get the directory structure correct. I have seen a few emails
>>> > > about the possible structure but no concrete "this is the way to go"
>>> > > type
>>> > statements.
>>> > > My thought is that these tests would be in
>>> > > api/src/test/java/com/cloud/api/*.java. Is this the right line of
>>> thought?
>>> > > Please let me know and I'll get the ball rolling. I've got a long
>>> > > way to go if I want to catch up to Yichi :)
>>> > >
>>> > > --
>>> > > Matthew Morrissey
>>> > > Software Engineer - SunGard Availability Services - 401 N. Broad
>>> > > Street, Philadelphia, PA 19108
>>> > > o: 215-446-2713 - e: matthew.morrissey@sungard.com
>>>
>>>
>>
>>
>> --
>> Matthew Morrissey
>> Software Engineer I - SunGard Availability Services - 401 N. Broad Street,
>> Philadelphia, PA 19108
>> o: 215-446-2713 - e: matthew.morrissey@sungard.com
[DISCUSS]How to write API Unit Tests
Posted by Min Chen <mi...@citrix.com>.
Hi there,
In working with API refactoring work, I cannot help wondering how we
should write Junit test cases for our APIs. Recently I saw that Chip has
merged some of his API unit test cases into master branch, and his api
unit test cases are written using Mockito, so no DB and real MS are needed
in running these Junit test cases. Here I want to raise this topic again
to get some clarifications on api unit test guidelines:
1. Should we require API unit test cases to be able to run without DB
existing or MS running?
2. If answer is yes, then I guess that we just need to use Mockito to
write our api unit test cases.
3. If answer is no, there are several follow-up questions to be clarified:
1) Does test case itself need to handle starting MS and stopping MS?
2) How should we set up a test DB? This may be needed for those list
APIs.
3) Testcases need to handle tear down test data afterwards.
Thanks
-min
Re: Unit tests
Posted by Chip Childers <ch...@sungard.com>.
I'd like to drop this branch (after moving completed tests over to
master). The reason that I created it was to specifically avoid
messing up the 4.0 work. Since we've moved on already, any issues
integrating the new tests into master?
-chip
On Tue, Oct 30, 2012 at 3:34 PM, Matthew Morrissey
<ma...@sungard.com> wrote:
> I would be working on everything in api/src/com/cloud/api/
>
> On Tue, Oct 30, 2012 at 1:52 PM, Manikanta Kattamuri <
> manikanta.kattamuri@sungard.com> wrote:
>
>> Hi All,
>>
>> Chip has created a branch for junit-tests.
>> There are some issues with folder structure in it, I sent a patch for
>> review 7776 on request board, once it is reviewed and committed the
>> structure will be set and all the units already written are in the new
>> structure.
>>
>> Mani
>>
>> -----Original Message-----
>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>> Sent: Tuesday, October 30, 2012 9:31 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: RE: Unit tests
>>
>> Matthew,
>>
>> Are you looking to write unit tests for which set of APIs? Is it the
>> management server APIs, plugin APIs, or resource APIs?
>>
>> Yup. Hugo's path is the correct one.
>>
>> --Alex
>>
>> > -----Original Message-----
>> > From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
>> > Sent: Tuesday, October 30, 2012 8:02 AM
>> > To: cloudstack-dev@incubator.apache.org
>> > Subject: RE: Unit tests
>> >
>> > Hey Matthew,
>> >
>> > Go go go !
>> >
>> > Put please put the tests in <sub_project_folder>/test/com/cloud/....
>> > That would keep it compatible with the existing location for unit
>> > tests and make it work with maven right away :-)
>> >
>> > Cheers,
>> >
>> > HUgo
>> >
>> > > -----Original Message-----
>> > > From: Matthew Morrissey [mailto:matthew.morrissey@sungard.com]
>> > > Sent: Tuesday, October 30, 2012 3:35 PM
>> > > To: cloudstack-dev@incubator.apache.org
>> > > Subject: Unit tests
>> > >
>> > > Hello all,
>> > >
>> > > I would like to begin writing unit tests for api/src/com/cloud/api
>> > > and I wanted to make sure that 1) it's an acceptable idea to
>> > > everyone and
>> > > 2) I get the directory structure correct. I have seen a few emails
>> > > about the possible structure but no concrete "this is the way to go"
>> > > type
>> > statements.
>> > > My thought is that these tests would be in
>> > > api/src/test/java/com/cloud/api/*.java. Is this the right line of
>> thought?
>> > > Please let me know and I'll get the ball rolling. I've got a long
>> > > way to go if I want to catch up to Yichi :)
>> > >
>> > > --
>> > > Matthew Morrissey
>> > > Software Engineer - SunGard Availability Services - 401 N. Broad
>> > > Street, Philadelphia, PA 19108
>> > > o: 215-446-2713 - e: matthew.morrissey@sungard.com
>>
>>
>
>
> --
> Matthew Morrissey
> Software Engineer I - SunGard Availability Services - 401 N. Broad Street,
> Philadelphia, PA 19108
> o: 215-446-2713 - e: matthew.morrissey@sungard.com
Re: Unit tests
Posted by Matthew Morrissey <ma...@sungard.com>.
I would be working on everything in api/src/com/cloud/api/
On Tue, Oct 30, 2012 at 1:52 PM, Manikanta Kattamuri <
manikanta.kattamuri@sungard.com> wrote:
> Hi All,
>
> Chip has created a branch for junit-tests.
> There are some issues with folder structure in it, I sent a patch for
> review 7776 on request board, once it is reviewed and committed the
> structure will be set and all the units already written are in the new
> structure.
>
> Mani
>
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Tuesday, October 30, 2012 9:31 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Unit tests
>
> Matthew,
>
> Are you looking to write unit tests for which set of APIs? Is it the
> management server APIs, plugin APIs, or resource APIs?
>
> Yup. Hugo's path is the correct one.
>
> --Alex
>
> > -----Original Message-----
> > From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
> > Sent: Tuesday, October 30, 2012 8:02 AM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: Unit tests
> >
> > Hey Matthew,
> >
> > Go go go !
> >
> > Put please put the tests in <sub_project_folder>/test/com/cloud/....
> > That would keep it compatible with the existing location for unit
> > tests and make it work with maven right away :-)
> >
> > Cheers,
> >
> > HUgo
> >
> > > -----Original Message-----
> > > From: Matthew Morrissey [mailto:matthew.morrissey@sungard.com]
> > > Sent: Tuesday, October 30, 2012 3:35 PM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: Unit tests
> > >
> > > Hello all,
> > >
> > > I would like to begin writing unit tests for api/src/com/cloud/api
> > > and I wanted to make sure that 1) it's an acceptable idea to
> > > everyone and
> > > 2) I get the directory structure correct. I have seen a few emails
> > > about the possible structure but no concrete "this is the way to go"
> > > type
> > statements.
> > > My thought is that these tests would be in
> > > api/src/test/java/com/cloud/api/*.java. Is this the right line of
> thought?
> > > Please let me know and I'll get the ball rolling. I've got a long
> > > way to go if I want to catch up to Yichi :)
> > >
> > > --
> > > Matthew Morrissey
> > > Software Engineer - SunGard Availability Services - 401 N. Broad
> > > Street, Philadelphia, PA 19108
> > > o: 215-446-2713 - e: matthew.morrissey@sungard.com
>
>
--
Matthew Morrissey
Software Engineer I - SunGard Availability Services - 401 N. Broad Street,
Philadelphia, PA 19108
o: 215-446-2713 - e: matthew.morrissey@sungard.com
RE: Unit tests
Posted by Manikanta Kattamuri <ma...@sungard.com>.
Hi All,
Chip has created a branch for junit-tests.
There are some issues with folder structure in it, I sent a patch for
review 7776 on request board, once it is reviewed and committed the
structure will be set and all the units already written are in the new
structure.
Mani
-----Original Message-----
From: Alex Huang [mailto:Alex.Huang@citrix.com]
Sent: Tuesday, October 30, 2012 9:31 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: Unit tests
Matthew,
Are you looking to write unit tests for which set of APIs? Is it the
management server APIs, plugin APIs, or resource APIs?
Yup. Hugo's path is the correct one.
--Alex
> -----Original Message-----
> From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
> Sent: Tuesday, October 30, 2012 8:02 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Unit tests
>
> Hey Matthew,
>
> Go go go !
>
> Put please put the tests in <sub_project_folder>/test/com/cloud/....
> That would keep it compatible with the existing location for unit
> tests and make it work with maven right away :-)
>
> Cheers,
>
> HUgo
>
> > -----Original Message-----
> > From: Matthew Morrissey [mailto:matthew.morrissey@sungard.com]
> > Sent: Tuesday, October 30, 2012 3:35 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Unit tests
> >
> > Hello all,
> >
> > I would like to begin writing unit tests for api/src/com/cloud/api
> > and I wanted to make sure that 1) it's an acceptable idea to
> > everyone and
> > 2) I get the directory structure correct. I have seen a few emails
> > about the possible structure but no concrete "this is the way to go"
> > type
> statements.
> > My thought is that these tests would be in
> > api/src/test/java/com/cloud/api/*.java. Is this the right line of
thought?
> > Please let me know and I'll get the ball rolling. I've got a long
> > way to go if I want to catch up to Yichi :)
> >
> > --
> > Matthew Morrissey
> > Software Engineer - SunGard Availability Services - 401 N. Broad
> > Street, Philadelphia, PA 19108
> > o: 215-446-2713 - e: matthew.morrissey@sungard.com
RE: Unit tests
Posted by Alex Huang <Al...@citrix.com>.
Matthew,
Are you looking to write unit tests for which set of APIs? Is it the management server APIs, plugin APIs, or resource APIs?
Yup. Hugo's path is the correct one.
--Alex
> -----Original Message-----
> From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
> Sent: Tuesday, October 30, 2012 8:02 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Unit tests
>
> Hey Matthew,
>
> Go go go !
>
> Put please put the tests in <sub_project_folder>/test/com/cloud/.... That
> would keep it compatible with the existing location for unit tests and make it
> work with maven right away :-)
>
> Cheers,
>
> HUgo
>
> > -----Original Message-----
> > From: Matthew Morrissey [mailto:matthew.morrissey@sungard.com]
> > Sent: Tuesday, October 30, 2012 3:35 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Unit tests
> >
> > Hello all,
> >
> > I would like to begin writing unit tests for api/src/com/cloud/api and
> > I wanted to make sure that 1) it's an acceptable idea to everyone and
> > 2) I get the directory structure correct. I have seen a few emails
> > about the possible structure but no concrete "this is the way to go" type
> statements.
> > My thought is that these tests would be in
> > api/src/test/java/com/cloud/api/*.java. Is this the right line of thought?
> > Please let me know and I'll get the ball rolling. I've got a long way
> > to go if I want to catch up to Yichi :)
> >
> > --
> > Matthew Morrissey
> > Software Engineer - SunGard Availability Services - 401 N. Broad
> > Street, Philadelphia, PA 19108
> > o: 215-446-2713 - e: matthew.morrissey@sungard.com
Re: Unit tests
Posted by Matthew Morrissey <ma...@sungard.com>.
Done and done. I'll start work ASAP :)
On Tue, Oct 30, 2012 at 11:02 AM, Hugo Trippaers <
HTrippaers@schubergphilis.com> wrote:
> Hey Matthew,
>
> Go go go !
>
> Put please put the tests in <sub_project_folder>/test/com/cloud/.... That
> would keep it compatible with the existing location for unit tests and make
> it work with maven right away :-)
>
> Cheers,
>
> HUgo
>
> > -----Original Message-----
> > From: Matthew Morrissey [mailto:matthew.morrissey@sungard.com]
> > Sent: Tuesday, October 30, 2012 3:35 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Unit tests
> >
> > Hello all,
> >
> > I would like to begin writing unit tests for api/src/com/cloud/api and I
> wanted
> > to make sure that 1) it's an acceptable idea to everyone and 2) I get the
> > directory structure correct. I have seen a few emails about the possible
> > structure but no concrete "this is the way to go" type statements.
> > My thought is that these tests would be in
> > api/src/test/java/com/cloud/api/*.java. Is this the right line of
> thought?
> > Please let me know and I'll get the ball rolling. I've got a long way to
> go if I
> > want to catch up to Yichi :)
> >
> > --
> > Matthew Morrissey
> > Software Engineer - SunGard Availability Services - 401 N. Broad Street,
> > Philadelphia, PA 19108
> > o: 215-446-2713 - e: matthew.morrissey@sungard.com
>
>
--
Matthew Morrissey
Software Engineer I - SunGard Availability Services - 401 N. Broad Street,
Philadelphia, PA 19108
o: 215-446-2713 - e: matthew.morrissey@sungard.com
RE: Unit tests
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
Hey Matthew,
Go go go !
Put please put the tests in <sub_project_folder>/test/com/cloud/.... That would keep it compatible with the existing location for unit tests and make it work with maven right away :-)
Cheers,
HUgo
> -----Original Message-----
> From: Matthew Morrissey [mailto:matthew.morrissey@sungard.com]
> Sent: Tuesday, October 30, 2012 3:35 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Unit tests
>
> Hello all,
>
> I would like to begin writing unit tests for api/src/com/cloud/api and I wanted
> to make sure that 1) it's an acceptable idea to everyone and 2) I get the
> directory structure correct. I have seen a few emails about the possible
> structure but no concrete "this is the way to go" type statements.
> My thought is that these tests would be in
> api/src/test/java/com/cloud/api/*.java. Is this the right line of thought?
> Please let me know and I'll get the ball rolling. I've got a long way to go if I
> want to catch up to Yichi :)
>
> --
> Matthew Morrissey
> Software Engineer - SunGard Availability Services - 401 N. Broad Street,
> Philadelphia, PA 19108
> o: 215-446-2713 - e: matthew.morrissey@sungard.com