9:26 a.m.
On Fri, 1 Mar 2013 17:01:36 +0100
Matthias Wessendorf <matzew(a)apache.org> wrote:
On Fri, Mar 1, 2013 at 4:04 PM, Summers Pittman
<supittma(a)redhat.com> wrote:
> On 03/01/2013 09:24 AM, Matthias Wessendorf wrote:
>> On Fri, Mar 1, 2013 at 3:17 PM, Summers Pittman <supittma(a)redhat.com>
>> wrote:
>>> On 03/01/2013 06:59 AM, Kris Borchers wrote:
>>>> On Mar 1, 2013, at 12:38 AM, Matthias Wessendorf
<matzew(a)apache.org>
>>>> wrote:
>>>>
>>>>> On Fri, Mar 1, 2013 at 2:02 AM, Douglas Campos <qmx(a)qmx.me>
wrote:
>>>>>> On 28/02/2013, at 20:07, Summers Pittman
<supittma(a)redhat.com> wrote:
>>>>>>
>>>>>>> aerogear-android-tests: This will house all of the Aerogear
tests for
>>>>>>> Android.
>>>>>> You mean moving all the tests? Can't this be only for
integration
>>>>>> tests, and the unit tests stay on the aerogear-android project?
>>>>> I'd also prefer to have the unit tests for each of the libs
>>>>> (aerogear-android + aerogear-android-support) being in there.
>>>> I can see one reason to have the unit tests in a separate project. I
>>>> assume both aerogear-android and aerogear-android-support would have
>>>> pretty much identical tests since their functionality should be the
>>>> same, right? It would be a pain to have to maintain multiple sets of
the
>>>> same tests across projects.
>>> This would be a benefit, yes.
>> ... ok - but I guess we have to be disciplined to exec. the tests...
>> It's too easy to forget that :)
> Not really, any decent build tool/IDE can be configured to run the test
> project with your code.
yes... I know.... but the key-word here is 'can' :-)
I bit late for the discussion. Fortunately, I agree with the outcome :-).
Separated tests does only make testing from IDE more complicated, otherwise it
has advantages. It should not be that difficult to set up a job that would
execute integration tests on our Jenkins instance in a regular manner. I
can work with Summers on that.
But yeah, lets do the split, for 1.0.0.Final
-M
>>
>>
>> -M
>>
>>
>>
>>>>> Only integration tests should be a totally independent project,
>>>>> consuming the other libs (aerogear-android +
aerogear-android-support)
>>>>> and having tests against em.
>>>>>
>>>>> -M
>>>>>
>>>>>
>>>>>> -- qmx
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> twitter: http://twitter.com/mwessendorf
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev