Well, if we had a slightly altered version of the service starter framework, we
could, in fact, have the ability to start services without new processes, in
the same JVM as the tests are running in, and use JUnit more often then not, I
believe. We'd just need some more simple to use programatic
+1 Peter.
On 3/12/2012 4:35 AM, Dan Creswell wrote:
Nice to hear from you Patricia...
On 2 December 2012 10:29, Patricia Shanahan wrote:
We presently have about 83 junit tests, at least 1/3 are rewritten qa
tests, so yes it is possible in test cases where you don't need services
or other infrastructure running.
On 3/12/2012 6:29 AM, Gregg Wonderly wrote:
I concur that include JUnit for unit testing would be a good thing, and th
I concur that include JUnit for unit testing would be a good thing, and then we
can move tests to JUnit if they are more likely unit tests than qa tests.
Gregg
On Dec 2, 2012, at 12:35 PM, Dan Creswell wrote:
> Nice to hear from you Patricia...
>
> On 2 December 2012 10:29, Patricia Shanahan
Thanks for getting my mind to switch to the right thought process.
Unit/Integration testing is what I meant when I said functionality testing.
This really makes the right division of testing as a starting point. At some
point, if a behavior becomes "spec", then tests demonstrating the correct
Nice to hear from you Patricia...
On 2 December 2012 10:29, Patricia Shanahan wrote:
> I hope you don't mind me throwing in some random comments on this. I think
> there are two types of testing that need to be distinguished, system and
> unit.
>
> A system test looks that the external behavior o
I hope you don't mind me throwing in some random comments on this. I
think there are two types of testing that need to be distinguished,
system and unit.
A system test looks that the external behavior of the whole system, so
what it is testing changes only when the API changes, and tests shoul
>>>
>>> If we can confirm 1373770 as stable, maybe we should branch a release off
>>> that, buying some time to stabilise what we're working on now.
>>>
>>>
>> I think we should do that. I'm also tempted to suggest we consider
>> limiting
>> our development until we've fixed these tests up. Or alte
...
On 30 November 2012 19:53, Gregg Wonderly wrote:
> I still wonder why it doesn't feel right that the test suite be in the same
> branch as the associated "release". Some of the new code needs new test that
> demonstrate "functionality" while other tests that demonstrate compatibility
> wi
Gregg Wonderly wrote:
I still wonder why it doesn't feel right that the test suite be in the same branch as the associated "release".
That was a comment I made, not that it's a pressing concern, right now
we need to focus on the ability of the harness to deal with concurrent
code and reducing
I still wonder why it doesn't feel right that the test suite be in the same
branch as the associated "release". Some of the new code needs new test that
demonstrate "functionality" while other tests that demonstrate compatibility
will be ran on each release without change. It seems to me, that
On 30/11/2012 12:27 AM, Dan Creswell wrote:
On 29 November 2012 13:11, Peter Firmstone wrote:
The last passing trunk versions:
Jdk6 Ubuntu 1407017
Solaris x861373770
Jdk7 Ubuntu 1379873
Windows 1373770
Revision 1373770 looks the most stable, I think all platforms w
On 29 November 2012 13:11, Peter Firmstone wrote:
> The last passing trunk versions:
>
> Jdk6 Ubuntu 1407017
> Solaris x861373770
> Jdk7 Ubuntu 1379873
> Windows 1373770
>
> Revision 1373770 looks the most stable, I think all platforms were passing
> on this, 1407017 o
The last passing trunk versions:
Jdk6 Ubuntu 1407017
Solaris x861373770
Jdk7 Ubuntu 1379873
Windows 1373770
Revision 1373770 looks the most stable, I think all platforms were
passing on this, 1407017 only passed on Ubuntu jdk6, nothing else.
If we can confirm 13737
On 29-11-12 13:07, Peter Firmstone wrote:
On 29/11/2012 10:04 PM, Simon IJskes - QCG wrote:
How about the following, we develop on a branch. Then we merge or
patch. We release. We pull a new branch of trunk. We merge/patch stuff
that did not make it in the release from the previous dev branch
On 29/11/2012 10:04 PM, Simon IJskes - QCG wrote:
On 29-11-12 12:34, Peter Firmstone wrote:
I think that's wise equally I'm pondering how you cope with trunk
moving on
and breaking a bunch of your tests for which there would be fixes in
the
trunk test suite. Are you happy doing merges as and
On 29-11-12 12:34, Peter Firmstone wrote:
I'm not sure, at this point I just know we've got problems, there's a
lot of coupling in the test suite and a lot of shared state; it's all
based on inheritance.
There are two test types:
1. Jini Standards Compliance
2. Implementation integration
On 29-11-12 12:34, Peter Firmstone wrote:
I think that's wise equally I'm pondering how you cope with trunk
moving on
and breaking a bunch of your tests for which there would be fixes in the
trunk test suite. Are you happy doing merges as and when or ???
I'm not sure, at this point I just k
On 29/11/2012 12:49 AM, Dan Creswell wrote:
It would be nice to have a stable qa suite branch for testing River
development and another for refactoring and developing the test suite
itself, without interfering with the development process of River. The
test suite requires maintenance too, but ri
On 28-11-12 15:49, Dan Creswell wrote:
I'd like to be able to run an experimental test suite with a stable River
trunk to test the test suite so to speak.
I think that's wise equally I'm pondering how you cope with trunk moving on
and breaking a bunch of your tests for which there would be
> It would be nice to have a stable qa suite branch for testing River
> development and another for refactoring and developing the test suite
> itself, without interfering with the development process of River. The
> test suite requires maintenance too, but right now it's a frightening
> prospect.
On 28 November 2012 13:50, Simon IJskes - QCG wrote:
> On 28-11-12 14:40, Peter Firmstone wrote:
>
>> Can we have a shared skunk branch? At present we each have our own
>> skunk branches.
>>
>
> Good idea. Lets try it.
>
>
I concur, who else should we seek agreement from?
>
> I think that wha
On 28-11-12 15:17, Peter Firmstone wrote:
It would be nice to have a stable qa suite branch for testing River
development and another for refactoring and developing the test suite
itself, without interfering with the development process of River. The
test suite requires maintenance too, but rig
On 28/11/2012 11:50 PM, Simon IJskes - QCG wrote:
On 28-11-12 14:40, Peter Firmstone wrote:
At stable points the skunk development branch can replace trunk. We
might have a period of refactoring and bug fixing, followed by a period
of stabilisation, testing and documenting, before replacing tr
On 28-11-12 14:40, Peter Firmstone wrote:
Can we have a shared skunk branch? At present we each have our own
skunk branches.
Good idea. Lets try it.
I think that what Sim was trying to achieve was a more cohesive
collaborative approach by developing in trunk, I think we could have
that with
I'd like to make a suggestion:
Can we have a shared skunk branch? At present we each have our own
skunk branches.
I think that what Sim was trying to achieve was a more cohesive
collaborative approach by developing in trunk, I think we could have
that with a shared skunk development branch.
26 matches
Mail list logo
