Menu
▾
▴
mockobjects-java-users — For people who use the mock objects libraries
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(30) |
Sep
(19) |
Oct
(3) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(11) |
Feb
(13) |
Mar
(10) |
Apr
(11) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(16) |
Sep
(14) |
Oct
(3) |
Nov
(9) |
Dec
|
| 2003 |
Jan
(5) |
Feb
(6) |
Mar
(9) |
Apr
(31) |
May
(25) |
Jun
(22) |
Jul
(28) |
Aug
(27) |
Sep
(19) |
Oct
(4) |
Nov
(7) |
Dec
(26) |
| 2004 |
Jan
(8) |
Feb
(13) |
Mar
(5) |
Apr
(8) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2005 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2008 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(10) |
Oct
(6) |
Nov
|
Dec
(36) |
| 2009 |
Jan
(3) |
Feb
(14) |
Mar
(13) |
Apr
(18) |
May
(35) |
Jun
(18) |
Jul
(27) |
Aug
(6) |
Sep
(2) |
Oct
|
Nov
|
Dec
(10) |
| 2010 |
Jan
(6) |
Feb
(1) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
|
From: Joe W. <jo...@tr...> - 2003-06-18 09:25:49
|
Chris has released this test documentation thingy. It's really nice :) --- I've blogged about it: http://joe.truemesh.com/blog/archives/agile/000047.html Chris has blogged about it: http://cgi.skizz.plus.com/blog/dev/archives/000113.html Website: http://agiledox.sourceforge.net/ You can run it instantly through WebStart: http://agiledox.sourceforge.net/testdox.jnlp --- Apologies for spam to those not interested. -joe Jeff Martin wrote: >Cheers sweetie. > >On Fri, 2003-06-06 at 12:03, Joe Walnes wrote: > > >>Yes! You'll get it shortly! >> >>-joe >> >>Jeff Martin wrote: >> >> >> >>>On Fri, 2003-06-06 at 08:12, Nat Pryce wrote: >>> >>> >>> >>> >>>>From: "Tim Mackinnon" <tim...@po...> >>>> >>>> >>>> >>>> >>>>>Really interestingly, one of the Thoughtworks teams finally took a long >>>>>standing idea and generated docs for a class where they parsed the test >>>>>names for a class and outputed: >>>>> >>>>>ClassX is an object that: >>>>>- Handles Zero Items Added >>>>>- Handles N Items With a Null >>>>>- Throw An Exception With An Empty List >>>>>- Allows Mixed Object Addition >>>>>etc. >>>>> >>>>> >>>>> >>>>> >>>>What a great idea! Are there any plans to release this tool? >>>> >>>> >>>> >>>> >>>I'd second that, cool way to make people think about test names >>> >>> >>> >>> >>> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Etnus, makers of TotalView, The best >>thread debugger on the planet. Designed with thread debugging features >>you've never dreamed of, try TotalView 6 free at www.etnus.com. >>_______________________________________________ >>Mockobjects-java-users mailing list >>Moc...@li... >>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users >> >> |
|
From: Steve F. <st...@m3...> - 2003-06-12 21:02:07
|
Someone else's framework, right? You're not going straight to the abstract class? :-o One option would be to wait until you have a need for a concrete sub-class and then test through that. Once you have two or more of these you can factor out the common testing (i.e. the bit which is implemented by the abstract parent) into a helper test class and use that in the tests for the concrete classes. You still have to test the subclasses and the helper tests will support you, or whoever else is using the framework, to write their own tests. Otherwise, sure. If the abstract class is already defined, then you can use the expectation library to help you construct a concrete subclass for testing. Whatever works. I'm not sure I'd call it a Mock, but I'm not sure that matters. S. Dan Cramer wrote: > It's part of a framework, and is the AbstractClass part of a Template > Method [Gof 325]. > > My goal is to test that the sequencing of method calls is correct, and I > was just wondering if a Mock sub-class is the way to go. |
|
From: Steve F. <st...@m3...> - 2003-06-12 20:00:39
|
Mocks are for emulating the environment around the object under test, rather than the object itself. So where did this abstract object came from? It should have come from refactoring common behaviour out of other classes, so it should be included in their tests. Steve Dan Cramer wrote: > How do I go about testing an abstract type? Do I create a mock that > sub-classes it and run tests against that? |
|
From: Dan C. <da...@dy...> - 2003-06-12 17:31:45
|
How do I go about testing an abstract type? Do I create a mock that sub-classes it and run tests against that? -- Dan Cramer |
|
From: Steve F. <st...@m3...> - 2003-06-11 22:06:43
|
Did you use the ant script? There are multiple version of some of the packages to correspond with multiple versions of jdk/j2ee S. lar...@fr... wrote: > > Hi There, > > I am new to Mock Objects. I down loaded the > mockobjects-src-0.09.tar.gz. I tried to compile. The examples did not > compile. The following lines have problems in class TestMailingList.java: > > mockPreparedStatement.setExpectedExecuteCalls(0); > mockStatement.setupResultSet(mockResultSet); > mockStatement.setExpectedQueryString(MailingList.LIST_SQL); > > > Please help! > > Thanks !!! > Larry Wang > (703) 903-3161 |
|
From: <lar...@fr...> - 2003-06-11 21:58:14
|
Hi There,
I am new to Mock Objects. I down loaded the
mockobjects-src-0.09.tar.gz. I tried to compile. The examples did not
compile. The following lines have problems in class TestMailingList.java:
mockPreparedStatement.setExpectedExecuteCalls(0);
mockStatement.setupResultSet(mockResultSet);
mockStatement.setExpectedQueryString(MailingList.LIST_SQL);
Please help!
Thanks !!!
Larry Wang
(703) 903-3161
|
|
From: Griffin C. <gri...@ya...> - 2003-06-09 14:46:53
|
I just wanted to drop a line to let everyone know of the new DotNetMock site. It's been in construction over the past couple of weeks, and the construction is ongoing. http://dotnetmock.sourceforge.net/tiki Check out the wiki for some new information about MO's and their use. This list will include: - MO Design Patterns & AntiPatterns - Creating MO's for 3rd Party components - Introducing MO's to a new systems & existing systems - Effective UI testing using MO's - Utilization of MO's throughout a team/company Since my project is .NET, in the beginning most of the code will be .NET based. But I am expecting to branch out into other languages, Java & Ruby especially. Drop me a line if anyone has any comments. As always, the wiki is open, so if you have something to add, go for it. Thanks, Griffin ===== Griffin Caprio "Your child against mine. The winner will be hailed, the loser will be booed until my throat hurts!" - Homer Simpson to Marge __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com |
|
From: Joe W. <jo...@tr...> - 2003-06-07 20:54:03
|
It should be released by Monday. http://cgi.skizz.plus.com/blog/dev/archives/000093.html Tim Mackinnon wrote: >Hey - Joe can you convince Chris to just make it available or is it >proprietory to where we work? If the latter- then its not to hard to jazz up >a new one (maybe as an eclipse plugin?) > >Tim > > > >>-----Original Message----- >>From: moc...@li... >>[mailto:moc...@li...]On Behalf Of >>Nat Pryce >>Sent: 06 June 2003 08:12 >>To: Tim Mackinnon; moc...@li... >>Cc: 'Mockobjects-Java-Dev' >>Subject: Re: [MO-java-dev] Javadoc is now online... >> >> >>From: "Tim Mackinnon" <tim...@po...> >> >> >>>Really interestingly, one of the Thoughtworks teams finally took a long >>>standing idea and generated docs for a class where they parsed the test >>>names for a class and outputed: >>> >>>ClassX is an object that: >>>- Handles Zero Items Added >>>- Handles N Items With a Null >>>- Throw An Exception With An Empty List >>>- Allows Mixed Object Addition >>>etc. >>> >>> >>What a great idea! Are there any plans to release this tool? >> >>Cheers, >> Nat. >> >>_______________________ >>Dr. Nathaniel Pryce >>B13media Ltd. >>http://www.b13media.com >>+44 (0)7712 526 661 >> >> >> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Etnus, makers of TotalView, The best >>thread debugger on the planet. Designed with thread debugging features >>you've never dreamed of, try TotalView 6 free at www.etnus.com. >>_______________________________________________ >>Mockobjects-java-dev mailing list >>Moc...@li... >>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev >> >>--- >>Incoming mail is certified Virus Free. >>Checked by AVG anti-virus system (http://www.grisoft.com). >>Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 >> >> >> >--- >Outgoing mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 > > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The best >thread debugger on the planet. Designed with thread debugging features >you've never dreamed of, try TotalView 6 free at www.etnus.com. >_______________________________________________ >Mockobjects-java-users mailing list >Moc...@li... >https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users > > |
|
From: Tim M. <tim...@po...> - 2003-06-07 18:29:17
|
Hey - Joe can you convince Chris to just make it available or is it proprietory to where we work? If the latter- then its not to hard to jazz up a new one (maybe as an eclipse plugin?) Tim > -----Original Message----- > From: moc...@li... > [mailto:moc...@li...]On Behalf Of > Nat Pryce > Sent: 06 June 2003 08:12 > To: Tim Mackinnon; moc...@li... > Cc: 'Mockobjects-Java-Dev' > Subject: Re: [MO-java-dev] Javadoc is now online... > > > From: "Tim Mackinnon" <tim...@po...> > > Really interestingly, one of the Thoughtworks teams finally took a long > > standing idea and generated docs for a class where they parsed the test > > names for a class and outputed: > > > > ClassX is an object that: > > - Handles Zero Items Added > > - Handles N Items With a Null > > - Throw An Exception With An Empty List > > - Allows Mixed Object Addition > > etc. > > What a great idea! Are there any plans to release this tool? > > Cheers, > Nat. > > _______________________ > Dr. Nathaniel Pryce > B13media Ltd. > http://www.b13media.com > +44 (0)7712 526 661 > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > _______________________________________________ > Mockobjects-java-dev mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 |
|
From: Jeff M. <jef...@mk...> - 2003-06-06 11:35:34
|
Cheers sweetie. On Fri, 2003-06-06 at 12:03, Joe Walnes wrote: > Yes! You'll get it shortly! >=20 > -joe >=20 > Jeff Martin wrote: >=20 > >On Fri, 2003-06-06 at 08:12, Nat Pryce wrote: > > =20 > > > >>From: "Tim Mackinnon" <tim...@po...> > >> =20 > >> > >>>Really interestingly, one of the Thoughtworks teams finally took a lon= g > >>>standing idea and generated docs for a class where they parsed the tes= t > >>>names for a class and outputed: > >>> > >>>ClassX is an object that: > >>>- Handles Zero Items Added > >>>- Handles N Items With a Null > >>>- Throw An Exception With An Empty List > >>>- Allows Mixed Object Addition > >>>etc. > >>> =20 > >>> > >>What a great idea! Are there any plans to release this tool? > >> =20 > >> > > > >I'd second that, cool way to make people think about test names > > > > =20 > > >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > _______________________________________________ > Mockobjects-java-users mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users --=20 jeff martin information technologist mkodo limited mobile: 44 (0) 78 55 478 331 phone: 44 (0) 20 77 29 45 45 email: jef...@mk... www.mkodo.com 73 Leonard St, London, EC2A 4QS. U.K |
|
From: Joe W. <jo...@tr...> - 2003-06-06 11:03:35
|
Yes! You'll get it shortly! -joe Jeff Martin wrote: >On Fri, 2003-06-06 at 08:12, Nat Pryce wrote: > > >>From: "Tim Mackinnon" <tim...@po...> >> >> >>>Really interestingly, one of the Thoughtworks teams finally took a long >>>standing idea and generated docs for a class where they parsed the test >>>names for a class and outputed: >>> >>>ClassX is an object that: >>>- Handles Zero Items Added >>>- Handles N Items With a Null >>>- Throw An Exception With An Empty List >>>- Allows Mixed Object Addition >>>etc. >>> >>> >>What a great idea! Are there any plans to release this tool? >> >> > >I'd second that, cool way to make people think about test names > > > |
|
From: Jeff M. <jef...@mk...> - 2003-06-06 10:39:13
|
On Fri, 2003-06-06 at 08:12, Nat Pryce wrote: > From: "Tim Mackinnon" <tim...@po...> > > Really interestingly, one of the Thoughtworks teams finally took a long > > standing idea and generated docs for a class where they parsed the test > > names for a class and outputed: > >=20 > > ClassX is an object that: > > - Handles Zero Items Added > > - Handles N Items With a Null > > - Throw An Exception With An Empty List > > - Allows Mixed Object Addition > > etc. >=20 > What a great idea! Are there any plans to release this tool? I'd second that, cool way to make people think about test names --=20 jeff martin information technologist mkodo limited mobile: 44 (0) 78 55 478 331 phone: 44 (0) 20 77 29 45 45 email: jef...@mk... www.mkodo.com 73 Leonard St, London, EC2A 4QS. U.K |
|
From: Nat P. <nat...@b1...> - 2003-06-06 07:22:20
|
From: "Tim Mackinnon" <tim...@po...>
> Really interestingly, one of the Thoughtworks teams finally took a long
> standing idea and generated docs for a class where they parsed the test
> names for a class and outputed:
>
> ClassX is an object that:
> - Handles Zero Items Added
> - Handles N Items With a Null
> - Throw An Exception With An Empty List
> - Allows Mixed Object Addition
> etc.
What a great idea! Are there any plans to release this tool?
Cheers,
Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661
|
|
From: Vincent M. <vm...@pi...> - 2003-06-06 06:41:54
|
> -----Original Message----- > From: Tim Mackinnon [mailto:tim...@po...] > Sent: 06 June 2003 02:32 > To: Vincent Massol; moc...@li... > Cc: 'Mockobjects-Java-Dev' > Subject: RE: [MO-java-dev] Javadoc is now online... > > Vincent - very interesting - its both good and bad: > > 1. I have never seen this libary and new nothing about it so it was a good > example to give to me I picked this project because I know it's Craig who wrote it and I know Craig always produce very nice javadoc. > 2. The first page was very good - the packages descriptions were excellent > - > the paragraph at the bottom of the page is duplicate of the top though (so > REFACTOR) He he... This is a *feature* of javadoc and it does this automatically with no duplication whatsoever in the code... ;-) > 3. I clicked on the first package - the first paragraph is yet again > another > copy of the aforementioned one... boy I hope the goal of the project > doesn't > change same here > 4. The interface descriptions are ok, but you know what? If they just had > better names in the first place I wouldn't need the text? Hmmmm Converter > - > I wonder what that does???? The text tells me so much... in fact the first > few words give it away "Gneral purpose data type converter... " - gosh if > they had called it DataTypeConverter I would really know what it was...??? > DynaBean and DynaClass are more obscure maybe the docs help (but hey we've > started writing docs now so we better keep going... Joke :-) I would still > try and think of a better name though Sure. But it's quite hard to pick good name immediately... and once the API has been released it's almost impossible... > 5. Class summaries - I got bored reading those - the names pretty much did > it for me > 6. ConversionExpection - WOW this comment really really made it very clear > to me... ;-) > 7. The Overview - ok now we're talking - leave out 3-6 and get to this > baby, > thats more like it.. but you know what the examples make me start to feel > nervous... Are they still up to date? If we refactor a method name would > the > docs still be up to date???? I had a quick look and it looks like they are > but really a hyperlink (or an inline inclusion of a real test method would > be so much more believable) would be better. Sure. But examples in the doc is what is really most useful. So you need to make the effort of maintaining. Now, some xdoclet stuff might make it possible to include source examples in the javadoc automatically. I've never done it though and I don't know if it is easy to do. > > 8. Although the section after "RowSetDynaClass (Disconnected ResultSet as > DynaBeans)" has a non function full paragraph hyperlink > 9. The sections after this they were obviously running out of steam and > the > formatting gets much worse and the content begins to border on the > obvious... > > Conclusion - > > Package descriptions seem like a great idea along with a 1 or 2 paragraph > description (but don't replicate it everywhere). The Introduction with > example snippets are great - link the real examples (and don't pretend to > have the full example in the text). Keep it tight and don't get too > carried > away as you run out of steam near the end. > > So yes Vincent - lets pick "cheap" documentation, and get the high value > stuff > > Tim > > p.s. Really interestingly, one of the Thoughtworks teams finally took a > long > standing idea and generated docs for a class where they parsed the test > names for a class and outputed: > > ClassX is an object that: > - Handles Zero Items Added > - Handles N Items With a Null > - Throw An Exception With An Empty List > - Allows Mixed Object Addition > etc. > > Guess what - its all based on writing tests with good names and with a bit > of creativity you get pretty good docs and are encouraged to write good > test > names... now thats Interesting dont you thing? That's a very interesting idea. I'm still a bit skeptical that you'll ever get good docs out of this though, but then I only want to be convinced :-) Thanks -Vincent > > > > -----Original Message----- > > From: moc...@li... > > [mailto:moc...@li...]On Behalf Of > > Vincent Massol > > Sent: 04 June 2003 07:53 > > To: 'Tim Mackinnon'; moc...@li... > > Cc: 'Mockobjects-Java-Dev' > > Subject: RE: [MO-java-dev] Javadoc is now online... > > > > > > > > > > > -----Original Message----- > > > From: Tim Mackinnon [mailto:tim...@po...] > > > Sent: 04 June 2003 01:41 > > > To: Vincent Massol; moc...@li... > > > Cc: 'Mockobjects-Java-Dev' > > > Subject: RE: [MO-java-dev] Javadoc is now online... > > > > > > oooh catty.... I can feel the scratches ;-) > > > > ;-) > > > > > > > > Yes - I personally think that docs are a crutch for writing bad code. > > > > I won't disagree with that. Writing good doc is for sure as hard as > > writing good code :-) > > > > > I've > > > tried both and run the experiments and found that if I just wrote > > better > > > code, had better method names, better variable names and better > > examples > > > and > > > tests - then the documents needed were very rudimentary. Yes its hard > > - > > > but > > > it pays off (the result being better code ). > > > > Sure but don't say the MockObjects framework is well documented! :-) > > > > > > > > I would prefer people spend effort on a Q&A or a short article than > > write > > > java doc - maybe its a smalltalk thing - once I've got past the > > > introduction > > > and seen an example I'm quite happy to browse working code that I know > > is > > > up > > > to date. > > > > You may be missing the overview.html and package.html part of javadoc > > which is probably the most fundamental one. > > > > > > > > We seem to disagree on this Vincent - but for all of your feedback on > > > requests for documentation I have tried to diligently go back to the > > code > > > and fix what was a problem there in the first place. > > > > Sure and I thank you for that! :-) > > > > Several things: > > - first, I personally don't care about the javadoc as I am a > > "power-user" of MockObjects and I have the code ready on my machine, > > etc. > > - Someone asked for it and I have uploaded it for that person. This is > > quite a logical request seen that there is almost no doc on MockObjects > > or Dyna Mocks and people are used to getting some information from the > > javadoc. > > - Javadoc can be very good. Have a look at the one for BeanUtils for > > example: http://jakarta.apache.org/commons/beanutils/api/index.html > > - I agree that the following is useless: > > > > /** > > * @return the name > > */ > > public String getName() > > { > > [...] > > > > and I would probably agree that there is no need to document this > > method. > > > > Some thoughts: > > > > 1/ I think you consider javadoc as a way to document what the logic of a > > method does whereas I consider javadoc as a way to explain how a given > > method fit in its environment, i.e. what's the purpose of the method is > > and how it relates to the other concepts of the > > application/frwk/whatever. > > > > 2/ Public API (not public methods) cannot be changed at will. A change > > to a public API breaks all its users. Thus, once you have decided on a > > name you cannot change it easily and you need to go through a long > > process. For example, the getName() above may not be explicit enough and > > should really be called getCustomerName() but I can't change it. So a > > comment saying that we are talking about a customer name might be > > helpful. > > > > 3/ For me the value of some piece of code is much more than the few > > lines themselves. It is: > > - has it been tested (i.e. suite of tests) > > - does it follow some well-defined coding conventions, i.e is it easy to > > read > > - is it enough documented so that users/extender can understand it (can > > be javadoc, unit tests, etc) and is the documentation readily accesible > > > > 4/ What would be nice is a doclet that takes the test code and put it in > > javadoc format, next to the behavior tested. Most people will not go to > > the source to get the doc so we need a way to simply publish the unit > > tests on the doc web site. > > > > > > > > But maybe we do need some documentation that says: > > > > > > - How to install it > > > - Which example to look at first > > > - What to do next > > > - How to read the code and use it as the documentation > > > > yep. These are all good topics for documentation. > > > > Now, I'll shut up because what we need are not words but actions and I > > am currently overwhelmed... > > > > Thanks Tim! > > -Vincent > > > > > > > > > > > Tim > > > > > > > -----Original Message----- > > > > From: moc...@li... > > > > [mailto:moc...@li...]On Behalf > > Of > > > > Vincent Massol > > > > Sent: 03 June 2003 08:59 > > > > To: moc...@li... > > > > Cc: 'Mockobjects-Java-Dev' > > > > Subject: [MO-java-dev] Javadoc is now online... > > > > > > > > > > > > FWIW, I've put the javadoc online: > > > > > > > > http://www.mockobjects.com/wiki/Javadocs > > > > > > > > Note: The MockObjects team thinks that javadoc is not needed and > > that > > > > good code should generally not need javadoc (i.e. it should be > > > > sufficiently expressive by itself). Thus you will find that this > > javadoc > > > > will not give you any explanation at all! In order to get > > explanation > > > > you are invited to read the code :-) > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.net email is sponsored by: eBay > > > > Get office equipment for less on eBay! > > > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > > > _______________________________________________ > > > > Mockobjects-java-dev mailing list > > > > Moc...@li... > > > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev > > > > > > > > --- > > > > Incoming mail is certified Virus Free. > > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 > > > > > > > --- > > > Outgoing mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Etnus, makers of TotalView, The best > > thread debugger on the planet. Designed with thread debugging features > > you've never dreamed of, try TotalView 6 free at www.etnus.com. > > _______________________________________________ > > Mockobjects-java-dev mailing list > > Moc...@li... > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev > > > > --- > > Incoming mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 |
|
From: Tim M. <tim...@po...> - 2003-06-06 00:27:52
|
Vincent - very interesting - its both good and bad: 1. I have never seen this libary and new nothing about it so it was a good example to give to me 2. The first page was very good - the packages descriptions were excellent - the paragraph at the bottom of the page is duplicate of the top though (so REFACTOR) 3. I clicked on the first package - the first paragraph is yet again another copy of the aforementioned one... boy I hope the goal of the project doesn't change 4. The interface descriptions are ok, but you know what? If they just had better names in the first place I wouldn't need the text? Hmmmm Converter - I wonder what that does???? The text tells me so much... in fact the first few words give it away "Gneral purpose data type converter... " - gosh if they had called it DataTypeConverter I would really know what it was...??? DynaBean and DynaClass are more obscure maybe the docs help (but hey we've started writing docs now so we better keep going... Joke :-) I would still try and think of a better name though 5. Class summaries - I got bored reading those - the names pretty much did it for me 6. ConversionExpection - WOW this comment really really made it very clear to me... ;-) 7. The Overview - ok now we're talking - leave out 3-6 and get to this baby, thats more like it.. but you know what the examples make me start to feel nervous... Are they still up to date? If we refactor a method name would the docs still be up to date???? I had a quick look and it looks like they are but really a hyperlink (or an inline inclusion of a real test method would be so much more believable) would be better. 8. Although the section after "RowSetDynaClass (Disconnected ResultSet as DynaBeans)" has a non function full paragraph hyperlink 9. The sections after this they were obviously running out of steam and the formatting gets much worse and the content begins to border on the obvious... Conclusion - Package descriptions seem like a great idea along with a 1 or 2 paragraph description (but don't replicate it everywhere). The Introduction with example snippets are great - link the real examples (and don't pretend to have the full example in the text). Keep it tight and don't get too carried away as you run out of steam near the end. So yes Vincent - lets pick "cheap" documentation, and get the high value stuff Tim p.s. Really interestingly, one of the Thoughtworks teams finally took a long standing idea and generated docs for a class where they parsed the test names for a class and outputed: ClassX is an object that: - Handles Zero Items Added - Handles N Items With a Null - Throw An Exception With An Empty List - Allows Mixed Object Addition etc. Guess what - its all based on writing tests with good names and with a bit of creativity you get pretty good docs and are encouraged to write good test names... now thats Interesting dont you thing? > -----Original Message----- > From: moc...@li... > [mailto:moc...@li...]On Behalf Of > Vincent Massol > Sent: 04 June 2003 07:53 > To: 'Tim Mackinnon'; moc...@li... > Cc: 'Mockobjects-Java-Dev' > Subject: RE: [MO-java-dev] Javadoc is now online... > > > > > > -----Original Message----- > > From: Tim Mackinnon [mailto:tim...@po...] > > Sent: 04 June 2003 01:41 > > To: Vincent Massol; moc...@li... > > Cc: 'Mockobjects-Java-Dev' > > Subject: RE: [MO-java-dev] Javadoc is now online... > > > > oooh catty.... I can feel the scratches ;-) > > ;-) > > > > > Yes - I personally think that docs are a crutch for writing bad code. > > I won't disagree with that. Writing good doc is for sure as hard as > writing good code :-) > > > I've > > tried both and run the experiments and found that if I just wrote > better > > code, had better method names, better variable names and better > examples > > and > > tests - then the documents needed were very rudimentary. Yes its hard > - > > but > > it pays off (the result being better code ). > > Sure but don't say the MockObjects framework is well documented! :-) > > > > > I would prefer people spend effort on a Q&A or a short article than > write > > java doc - maybe its a smalltalk thing - once I've got past the > > introduction > > and seen an example I'm quite happy to browse working code that I know > is > > up > > to date. > > You may be missing the overview.html and package.html part of javadoc > which is probably the most fundamental one. > > > > > We seem to disagree on this Vincent - but for all of your feedback on > > requests for documentation I have tried to diligently go back to the > code > > and fix what was a problem there in the first place. > > Sure and I thank you for that! :-) > > Several things: > - first, I personally don't care about the javadoc as I am a > "power-user" of MockObjects and I have the code ready on my machine, > etc. > - Someone asked for it and I have uploaded it for that person. This is > quite a logical request seen that there is almost no doc on MockObjects > or Dyna Mocks and people are used to getting some information from the > javadoc. > - Javadoc can be very good. Have a look at the one for BeanUtils for > example: http://jakarta.apache.org/commons/beanutils/api/index.html > - I agree that the following is useless: > > /** > * @return the name > */ > public String getName() > { > [...] > > and I would probably agree that there is no need to document this > method. > > Some thoughts: > > 1/ I think you consider javadoc as a way to document what the logic of a > method does whereas I consider javadoc as a way to explain how a given > method fit in its environment, i.e. what's the purpose of the method is > and how it relates to the other concepts of the > application/frwk/whatever. > > 2/ Public API (not public methods) cannot be changed at will. A change > to a public API breaks all its users. Thus, once you have decided on a > name you cannot change it easily and you need to go through a long > process. For example, the getName() above may not be explicit enough and > should really be called getCustomerName() but I can't change it. So a > comment saying that we are talking about a customer name might be > helpful. > > 3/ For me the value of some piece of code is much more than the few > lines themselves. It is: > - has it been tested (i.e. suite of tests) > - does it follow some well-defined coding conventions, i.e is it easy to > read > - is it enough documented so that users/extender can understand it (can > be javadoc, unit tests, etc) and is the documentation readily accesible > > 4/ What would be nice is a doclet that takes the test code and put it in > javadoc format, next to the behavior tested. Most people will not go to > the source to get the doc so we need a way to simply publish the unit > tests on the doc web site. > > > > > But maybe we do need some documentation that says: > > > > - How to install it > > - Which example to look at first > > - What to do next > > - How to read the code and use it as the documentation > > yep. These are all good topics for documentation. > > Now, I'll shut up because what we need are not words but actions and I > am currently overwhelmed... > > Thanks Tim! > -Vincent > > > > > > > Tim > > > > > -----Original Message----- > > > From: moc...@li... > > > [mailto:moc...@li...]On Behalf > Of > > > Vincent Massol > > > Sent: 03 June 2003 08:59 > > > To: moc...@li... > > > Cc: 'Mockobjects-Java-Dev' > > > Subject: [MO-java-dev] Javadoc is now online... > > > > > > > > > FWIW, I've put the javadoc online: > > > > > > http://www.mockobjects.com/wiki/Javadocs > > > > > > Note: The MockObjects team thinks that javadoc is not needed and > that > > > good code should generally not need javadoc (i.e. it should be > > > sufficiently expressive by itself). Thus you will find that this > javadoc > > > will not give you any explanation at all! In order to get > explanation > > > you are invited to read the code :-) > > > > > > Thanks > > > -Vincent > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: eBay > > > Get office equipment for less on eBay! > > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > > _______________________________________________ > > > Mockobjects-java-dev mailing list > > > Moc...@li... > > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev > > > > > > --- > > > Incoming mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 > > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > _______________________________________________ > Mockobjects-java-dev mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 |
|
From: Steve F. <st...@m3...> - 2003-06-05 20:47:33
|
I think Vincent has some valid points. What's missing is not the dumb "conformant" javadoc, but the more explanatory background writing, and the package and class docs may be as a good a place to put them as anywhere. Of course, we're all short of time. The purpose of this kind of writing is different from the sort of doc that we love to hate. S. |
|
From: Nat P. <nat...@b1...> - 2003-06-04 08:18:17
|
Perhaps, for starters, it would be a good idea to take interesting threads
from the mailing list and copy them on the Wiki, in edited form, to be
preserved for posterity. This idea is already used The Ruby wiki. These
threads could then be refactored into other kinds of documentation.
For example, the recent a.equals(b) vs b.equals(a) thread would be a good
candidate to move to the wiki.
Cheers,
Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661
----- Original Message -----
From: "Tim Mackinnon" <tim...@po...>
To: "Vincent Massol" <vm...@pi...>;
<moc...@li...>
Cc: "'Mockobjects-Java-Dev'" <moc...@li...>
Sent: Wednesday, June 04, 2003 12:40 AM
Subject: [MO-java-users] RE: [MO-java-dev] Javadoc is now online...
> oooh catty.... I can feel the scratches ;-)
>
> Yes - I personally think that docs are a crutch for writing bad code. I've
> tried both and run the experiments and found that if I just wrote better
> code, had better method names, better variable names and better examples
and
> tests - then the documents needed were very rudimentary. Yes its hard -
but
> it pays off (the result being better code ).
>
> I would prefer people spend effort on a Q&A or a short article than write
> java doc - maybe its a smalltalk thing - once I've got past the
introduction
> and seen an example I'm quite happy to browse working code that I know is
up
> to date.
>
> We seem to disagree on this Vincent - but for all of your feedback on
> requests for documentation I have tried to diligently go back to the code
> and fix what was a problem there in the first place.
>
> But maybe we do need some documentation that says:
>
> - How to install it
> - Which example to look at first
> - What to do next
> - How to read the code and use it as the documentation
>
>
> Tim
>
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf Of
> > Vincent Massol
> > Sent: 03 June 2003 08:59
> > To: moc...@li...
> > Cc: 'Mockobjects-Java-Dev'
> > Subject: [MO-java-dev] Javadoc is now online...
> >
> >
> > FWIW, I've put the javadoc online:
> >
> > http://www.mockobjects.com/wiki/Javadocs
> >
> > Note: The MockObjects team thinks that javadoc is not needed and that
> > good code should generally not need javadoc (i.e. it should be
> > sufficiently expressive by itself). Thus you will find that this javadoc
> > will not give you any explanation at all! In order to get explanation
> > you are invited to read the code :-)
> >
> > Thanks
> > -Vincent
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: eBay
> > Get office equipment for less on eBay!
> > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
|
|
From: Vincent M. <vm...@pi...> - 2003-06-04 07:19:09
|
> -----Original Message----- > From: Tim Mackinnon [mailto:tim...@po...] > Sent: 04 June 2003 01:41 > To: Vincent Massol; moc...@li... > Cc: 'Mockobjects-Java-Dev' > Subject: RE: [MO-java-dev] Javadoc is now online... > > oooh catty.... I can feel the scratches ;-) ;-) > > Yes - I personally think that docs are a crutch for writing bad code. I won't disagree with that. Writing good doc is for sure as hard as writing good code :-) > I've > tried both and run the experiments and found that if I just wrote better > code, had better method names, better variable names and better examples > and > tests - then the documents needed were very rudimentary. Yes its hard - > but > it pays off (the result being better code ). Sure but don't say the MockObjects framework is well documented! :-) > > I would prefer people spend effort on a Q&A or a short article than write > java doc - maybe its a smalltalk thing - once I've got past the > introduction > and seen an example I'm quite happy to browse working code that I know is > up > to date. You may be missing the overview.html and package.html part of javadoc which is probably the most fundamental one. > > We seem to disagree on this Vincent - but for all of your feedback on > requests for documentation I have tried to diligently go back to the code > and fix what was a problem there in the first place. Sure and I thank you for that! :-) Several things: - first, I personally don't care about the javadoc as I am a "power-user" of MockObjects and I have the code ready on my machine, etc. - Someone asked for it and I have uploaded it for that person. This is quite a logical request seen that there is almost no doc on MockObjects or Dyna Mocks and people are used to getting some information from the javadoc. - Javadoc can be very good. Have a look at the one for BeanUtils for example: http://jakarta.apache.org/commons/beanutils/api/index.html - I agree that the following is useless: /** * @return the name */ public String getName() { [...] and I would probably agree that there is no need to document this method. Some thoughts: 1/ I think you consider javadoc as a way to document what the logic of a method does whereas I consider javadoc as a way to explain how a given method fit in its environment, i.e. what's the purpose of the method is and how it relates to the other concepts of the application/frwk/whatever. 2/ Public API (not public methods) cannot be changed at will. A change to a public API breaks all its users. Thus, once you have decided on a name you cannot change it easily and you need to go through a long process. For example, the getName() above may not be explicit enough and should really be called getCustomerName() but I can't change it. So a comment saying that we are talking about a customer name might be helpful. 3/ For me the value of some piece of code is much more than the few lines themselves. It is: - has it been tested (i.e. suite of tests) - does it follow some well-defined coding conventions, i.e is it easy to read - is it enough documented so that users/extender can understand it (can be javadoc, unit tests, etc) and is the documentation readily accesible 4/ What would be nice is a doclet that takes the test code and put it in javadoc format, next to the behavior tested. Most people will not go to the source to get the doc so we need a way to simply publish the unit tests on the doc web site. > > But maybe we do need some documentation that says: > > - How to install it > - Which example to look at first > - What to do next > - How to read the code and use it as the documentation yep. These are all good topics for documentation. Now, I'll shut up because what we need are not words but actions and I am currently overwhelmed... Thanks Tim! -Vincent > > > Tim > > > -----Original Message----- > > From: moc...@li... > > [mailto:moc...@li...]On Behalf Of > > Vincent Massol > > Sent: 03 June 2003 08:59 > > To: moc...@li... > > Cc: 'Mockobjects-Java-Dev' > > Subject: [MO-java-dev] Javadoc is now online... > > > > > > FWIW, I've put the javadoc online: > > > > http://www.mockobjects.com/wiki/Javadocs > > > > Note: The MockObjects team thinks that javadoc is not needed and that > > good code should generally not need javadoc (i.e. it should be > > sufficiently expressive by itself). Thus you will find that this javadoc > > will not give you any explanation at all! In order to get explanation > > you are invited to read the code :-) > > > > Thanks > > -Vincent > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: eBay > > Get office equipment for less on eBay! > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > _______________________________________________ > > Mockobjects-java-dev mailing list > > Moc...@li... > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev > > > > --- > > Incoming mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 |
|
From: Tim M. <tim...@po...> - 2003-06-03 23:36:45
|
oooh catty.... I can feel the scratches ;-) Yes - I personally think that docs are a crutch for writing bad code. I've tried both and run the experiments and found that if I just wrote better code, had better method names, better variable names and better examples and tests - then the documents needed were very rudimentary. Yes its hard - but it pays off (the result being better code ). I would prefer people spend effort on a Q&A or a short article than write java doc - maybe its a smalltalk thing - once I've got past the introduction and seen an example I'm quite happy to browse working code that I know is up to date. We seem to disagree on this Vincent - but for all of your feedback on requests for documentation I have tried to diligently go back to the code and fix what was a problem there in the first place. But maybe we do need some documentation that says: - How to install it - Which example to look at first - What to do next - How to read the code and use it as the documentation Tim > -----Original Message----- > From: moc...@li... > [mailto:moc...@li...]On Behalf Of > Vincent Massol > Sent: 03 June 2003 08:59 > To: moc...@li... > Cc: 'Mockobjects-Java-Dev' > Subject: [MO-java-dev] Javadoc is now online... > > > FWIW, I've put the javadoc online: > > http://www.mockobjects.com/wiki/Javadocs > > Note: The MockObjects team thinks that javadoc is not needed and that > good code should generally not need javadoc (i.e. it should be > sufficiently expressive by itself). Thus you will find that this javadoc > will not give you any explanation at all! In order to get explanation > you are invited to read the code :-) > > Thanks > -Vincent > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Mockobjects-java-dev mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003 |
|
From: Vincent M. <vm...@pi...> - 2003-06-03 14:40:24
|
Hi Ringo, MockObjects 0.09 has simply introduced the new dyna mock feature. It does not mean that the static mocks should not be used. They present some nice advantages, like offering a cleaner interface, strong typing, work without interfaces, etc. But they are not available for everything, so you need both dyna mock and static mocks. In any case, you should present the 0.09 version to your team. Hope it helps, -Vincent > -----Original Message----- > From: moc...@li... > [mailto:moc...@li...] On Behalf Of > DeS...@em... > Sent: 03 June 2003 16:25 > To: moc...@li... > Subject: [MO-java-users] What's the way to go? DynaMock? > > Hello, > > Together with a colleague, I am rolling out test-driven development within > the company. We already presented an introduction to unit testing. Next > week, we have planned sessions on advanced techniques like MockObjects. > Since most of the people in the company don't know a lot about > MockObjects, > we can start from scratch and present what we think it should be. However, > with the introduction of DynaMock in release 0.09, I am unsure what to > present. Should I present MockObjects based on the 0.07 incarnation, or > should I go all the way to 0.09 and DynaMock? What's the future going to > be? > > Ringo > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Mockobjects-java-users mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users |
|
From: <DeS...@em...> - 2003-06-03 14:26:13
|
Hello, Together with a colleague, I am rolling out test-driven development within the company. We already presented an introduction to unit testing. Next week, we have planned sessions on advanced techniques like MockObjects. Since most of the people in the company don't know a lot about MockObjects, we can start from scratch and present what we think it should be. However, with the introduction of DynaMock in release 0.09, I am unsure what to present. Should I present MockObjects based on the 0.07 incarnation, or should I go all the way to 0.09 and DynaMock? What's the future going to be? Ringo |
|
From: Vincent M. <vm...@pi...> - 2003-06-03 07:59:23
|
FWIW, I've put the javadoc online: http://www.mockobjects.com/wiki/Javadocs Note: The MockObjects team thinks that javadoc is not needed and that good code should generally not need javadoc (i.e. it should be sufficiently expressive by itself). Thus you will find that this javadoc will not give you any explanation at all! In order to get explanation you are invited to read the code :-) Thanks -Vincent |
|
From: Tom S. <tj...@fe...> - 2003-05-27 20:17:21
|
I'm trying to test a DAO class to "insert" using the CommonMockPreparedStatement class. The problem that I'm running into is that one of the expected values needed for the prepared statement isn't known until after the DAO insert method returns (the primary key). When my DAO code calls the setInteger method on the prepared statement it fails immeadately because its being checked immediately. What I think I want to do is to call setFailOnVerify but this method is on the ExpectationSet mySetParameters which is private inside the CommonMockPreparedStatement. Does anyone have a workaround? Re:'s TJS |
|
From: Steve F. <st...@m3...> - 2003-05-21 22:23:17
|
>> The release of 0.08 contians only the compiled classes. I don't >> have access to CVS. If I want the source code and the docs, how can >> I get them? just released a zip file with all the sources, and added the j2ee 1.2.1 combinations as well. S. |
|
From: Daniel P. <PO...@uk...> - 2003-05-21 13:59:33
|
Hi, I have downloaded the binary dist. of MockObjects 0.08 and am writing some simple play tests - but I am unsure how to use the expects(java.lang.String, com.mockobjects.dynamic.MockCall) method. Could anyone give me a code sample to demonstrate use of the MockCall objects? Cheers, Dan p.s. - I understand the main concepts of MockObjects but haven't used the mockobjects api before... Dan Pollitt Software Engineer - IBM Member of the Agile Alliance |
190 messages has been excluded from this view by a project administrator.
