Menu
▾
▴
rmock-developer — For rMock develper discussions
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(5) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2008 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joakim O. <joa...@gm...> - 2005-12-22 07:54:35
|
Hi list!
Just to create some noise on the list here is an update of what is currentl=
y
going on:
Yesterday we had a small but significant breakthrough in rDoc, for the firs=
t
time we were able to extract example code from a testcase
and insert it into something that can become documentation. This is not yet
checked in since we have to solve some javaCC + maven issues
but here is how it works:
1. just make sure that rdoc.jar is in your classpath (along with velocity
and a patched version of qdox)
2. add rdoc comments to your testcase like this:
public class MyTest extends RMockTestCase {
SomeObject object =3D new SomeObejct();
/*!rdoc.beginSnippet(someIdentifier)*/
// this code will be in the documentation, including this
comment
object.doSomething();
/*!rdoc.end*/
// this code will not be in the documentation
object.doSomethingElse();
}
This is admittedly not much but quite a few things have to be in place to
get this much, hopefully it is more of a downhill ride from here.
We have also noticed that rDoc is a bad name, there is already a ruby tool
called rDoc. We need a new name and our current suggestion is tddoc
as in test driven documentation. Any suggestion for a new name for rDoc is
most welcome.
/Joakim Ohlrogge
|
|
From: Daniel B. <dan...@gm...> - 2005-11-27 21:28:54
|
Another week, another release. The work this last week has been focused on updating rMock to support the documentation-generating sister-project rDoc (available in CVS only), so there are no new "visible" features this week. In rDoc, we have been able to generate sequence diagrams from invocation events from the mocked, stubbed and monitored objects. The diagrams are still not presentable, but we hope to get there soon, partly with the AspectJ proxy factory. The coming week we hope to * Rework the ExpectationGenerator (rMock) * Improve our documentation generation (rDoc). * Add a comparison between rMock, EasyMock and jMock for our potential users to make a more informed decision on choosing mock framework (rMock) * Add support to have singleton services on the hub (rMock) * Begin working on the AspectJ proxy factory (rMock) You might wonder what is keeping us from making a "real" release (i.e. not alpha, beta, rc etc). The reason is that, as we see rMock, there are mainly two parts: 1) The mock framework with asserts and setups etc 2) The plugin model and the message hub We don't expect 1) to change much. We will add features along the way, e.g. more specialized constraints, but the core mocking API won't change under 2.x. What might still change is 2). We are getting there, but we still discover things that changes too big a parts of the message hub and plugin model to have it in a stable release. At the moment, we who develop rMock are the only ones concerned with that, but eventually we hope that third party providers will extend rMock with new features using the hub. Cheers Daniel and the rMock team -- __________________________ Dan...@Gm... |
|
From: Joakim O. <joa...@gm...> - 2005-11-21 12:26:35
|
That may be a good idea, alternatively we go through changes xml manually post-generation. On 11/21/05, Daniel Brolund <dan...@gm...> wrote: > Good idea! > > remove: <message> > > can also be used. > > I assume commits without the initial keyword are not added to the > changes.xml to avoid making the the file too detailed? > > Cheers > Daniel > > On 11/21/05, Joakim Ohlrogge <joa...@gm...> wrote: > > In our changes.xml write what we fixed, what whe added and what we upda= ted. > > Could we use that format when committing? That way we could generate a > > changes.xml for each version. I suggest the following check in > > standard: > > > > add: <message> > > fix: <message> > > update: <message> > > > > From that we could then create a loginfo-script that generate > > changes.xml and update it in CVS (if sourceforge permits that). If sf > > don't permit that we could easially do the same offline when > > releasing. > > > > /J > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > > Register for a JBoss Training Course. Free Certification Exam > > for All Training Attendees Through End of 2005. For more info visit: > > http://ads.osdn.com/?ad_idv28&alloc_id=16845&opclick > > _______________________________________________ > > Rmock-developer mailing list > > Rmo...@li... > > https://lists.sourceforge.net/lists/listinfo/rmock-developer > > > > > -- > __________________________ > Dan...@Gm... > |
|
From: Daniel B. <dan...@gm...> - 2005-11-21 12:24:01
|
Good idea! remove: <message> can also be used. I assume commits without the initial keyword are not added to the changes.xml to avoid making the the file too detailed? Cheers Daniel On 11/21/05, Joakim Ohlrogge <joa...@gm...> wrote: > In our changes.xml write what we fixed, what whe added and what we update= d. > Could we use that format when committing? That way we could generate a > changes.xml for each version. I suggest the following check in > standard: > > add: <message> > fix: <message> > update: <message> > > From that we could then create a loginfo-script that generate > changes.xml and update it in CVS (if sourceforge permits that). If sf > don't permit that we could easially do the same offline when > releasing. > > /J > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_idv28&alloc_id=16845&opclick > _______________________________________________ > Rmock-developer mailing list > Rmo...@li... > https://lists.sourceforge.net/lists/listinfo/rmock-developer > -- __________________________ Dan...@Gm... |
|
From: Joakim O. <joa...@gm...> - 2005-11-21 12:14:18
|
In our changes.xml write what we fixed, what whe added and what we updated. Could we use that format when committing? That way we could generate a changes.xml for each version. I suggest the following check in standard: add: <message> fix: <message> update: <message> From that we could then create a loginfo-script that generate changes.xml and update it in CVS (if sourceforge permits that). If sf don't permit that we could easially do the same offline when releasing. /J |
|
From: Joakim O. <joa...@gm...> - 2005-11-20 21:29:51
|
Another weekly release of rMock has just been made: beta-4 Changes since last week The main visible contribution this week was the expectation generator (see link "Getting started" in left navigation). To support it we have added begins-with and ends-with constraints to the ConstraintFactory (the "is" reference in RMockTestCase). Under the hood we are still working on the documentation features, refactoring the framework to suit the documentation needs. We hope to be able to pull together the first generated documentation (including a rudimentary sequence diagram) during the next week. Cheers The rMock team |
|
From: Daniel B. <dan...@gm...> - 2005-11-13 15:59:09
|
Hi everybody! The beta 3 version of rMock is out. This week we added some new factory methods on the constraint factory, improved the array comparison and messaging functionality and made some internal refactorings. The next week we hope to get a shot at the documenting features. If you have any questions about rMock, please post them here. We want your input and questions to improve the framework! Regards Daniel Brolund |
|
From: Daniel B. <dan...@gm...> - 2005-11-06 15:57:55
|
rMock 2.0.0-beta-2 released! The rMock team is proud to present the beta-2 version of rMock 2.0.0 as part of the weekly release heartbeat. The focus for the last week was to get the first version of the message bus in place. No changes to the api was needed this time, and since no bugs were found no bugs were fixed. We will continue the work on the message bus and the documentation features of rMock in the newly created module rDoc (only in cvs at the moment). The plan is to integrate that module as a plugin into rMock to enable automated, up-to-date project documentation with minimal effort cost. Changes: No API changes this time. * Added first version of message bus * Created rDoc project for documenting testcases * Created TestCaseEventSource, InvocationEventSource and an ExpectationEventSource and added it to the message bus. Created a corresponding TestCaseListener, InvocationListener and an ExpectationListener to use with the event source over the message bus. /Daniel Brolund on behalf of the rMock team P.S. Please report any issues, feature requests, documentation requests or bugs to us and we will address it a.s.a.p., normally in the next release. We don't need you to be formal in any way, just drop a line or two on this list or to one of the rMock team members. -- __________________________ Dan...@Gm... |
|
From: Daniel B. <dan...@gm...> - 2005-11-06 15:53:16
|
rMock 2.0.0-beta-2 released! The rMock team is proud to present the beta-2 version of rMock 2.0.0 as part of the weekly release heartbeat. The focus for the last week was to get the first version of the message bus in place. No changes to the api was needed this time, and since no bugs were found no bugs were fixed. We will continue the work on the message bus and the documentation features of rMock in the newly created module rDoc (only in cvs at the moment). The plan is to integrate that module as a plugin into rMock to enable automated, up-to-date project documentation with minimal effort cost. Changes: No API changes this time. * Added first version of message bus * Created rDoc project for documenting testcases * Created TestCaseEventSource, InvocationEventSource and an ExpectationEventSource and added it to the message bus. Created a corresponding TestCaseListener, InvocationListener and an ExpectationListener to use with the event source over the message bus. /Daniel Brolund on behalf of the rMock team P.S. Please report any issues, feature requests, documentation requests or bugs to us and we will address it a.s.a.p., normally in the next release. We don't need you to be formal in any way, just drop a line or two on this list or to one of the rMock team members. |
|
From: Joakim O. <joa...@gm...> - 2005-11-03 20:37:58
|
We are now in Beta and things feel quite stable. RMock 2.0.0 is being used in several projects since alpha 1. The feedback we have had so far is positive but sparse. Dynamic suites really gives good perormance. One project that I know of that is using them cut their build-time from 7 minutes to 2.5. In RMock testing went 95% faster with Dynamic suites than without. So if you haven't tried them, please do! The problems we have investigated with dynamic suites have been related to Java 1.5 and simply switching from starting one JVM per test-class to starting the JVM only once (stateful tests that surface when the JVM is no longer restared between each test. I am currently using RMock myself in my current project. The project I'm in gives the opportunity to unit-test with threads. I have thought of several tools that could be included in RMock in order to simplify the extremely hard task of testing threaded code. I expect to add some of those Ideas in a later version. Ongoing work: * We have started to introduce the message bus to make RMock extendable. The Bus in it's current form is sufficient to configure RMock in its current state but far from production stable. * We are breaking dependency cycles, partly by using the new Bus. If you are extending rMock, depend on interfaces and not implementations and you should be fine, although some things can still move until we are production stable. Using the rMock JUnit integration via dynamic suites and RMockTestCase will be safe though and we won't change anything public. * We have created a Sub-project rDoc where we will start on the features that made us begin developing rMock in the first place: making a software system self documenting with the help of testcases. I just saw the first sequence diagram 10 minutes ago and am really excited about where rMock is heading. We in the rMock team will have a small conference about rMock soon, any feedback would be most welcome so we know what we are doing right and what we could do better. /Joakim Ohlrogge |
1 message has been excluded from this view by a project administrator.
