etester-devel — Developer list for etester

[Etester-devel] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[Etester-devel] xml reporting and comment

[<dm...@cs...>]

Hi,

I have added to_xml to generate xml output to stdout.  In order to facilitate
this, I have made restrictions on the comments allowed for test cases.  This
xml output will be parsed by edt to natively display test results.  Please do a
cvs update (etester2-dev) and test against current test suites.  Remember, it
may be necessary to rewrite some of the strings passed via comment(s :
STRING).

EtesterGUI will be rendered obsolete as EDT will be able to display test suite
results.  

- Dave Makalsky

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Etester-devel] Re: eTester

[<dm...@cs...>]

Hi:

I have no objections to these points.

Cheers,

DM


Quoting Gunnar Gotshalks <gu...@cs...>:

> Hi All,
> 
> Bil pointed out the following and I have some comments as a result of 
> working with students in the Prism lab.
> 
> At 4:12 PM -0400 9/15/03, Vassilios Tzerpos wrote:
> >    1. The blurb on etester at the web page is outdated. Unfo, I 
> >don't have permission to change it. We should probably mention that 
> >etester 2.1.2 is the official 3311 version. I would personally 
> >favour putting the etester2.1.2.zip file as well as the etester-gui 
> >one on the course web page, but if you feel otherwise, no problem.
> 
> Yes I agree with standardizing eTester and will try to
> 
> 1 -- I am now totally against any changes in what students are to use 
> after ONE MONTH BEFORE CLASSES BEGIN.   I guess I will have to put in 
> emergency time yet again but no more.  Changes are at least as time 
> consuming as doing the original and many more errors result.  As I 
> said to Jonathan the other day, eTester is taking up the majority 
> part of my time with Eiffel and the course and I do not see that it 
> is such a significant topic to take up so much effort.   It is 
> confusing to me, students get confusing messages which lowers their 
> confidence in the quality and benefit of the course.
> 
> 2 -- I now do not think that having etester precompiled is a good 
> idea.  The Prism ace files are different from what they have at home 
> and are different from my examples.   We should strive that our use 
> of Eiffel, Estudio and eTester are as identical as possible on all 
> environments.   Aside from path names, the same ace file should be 
> usable. If Eiffel can handle relative path names, which I did not 
> know it could as examples from a few years ago did not have relative 
> paths, then we should set up the template for Eiffel projects where 
> the root class and etester have the same relative path on all systems.
> 
> 3 -- Students are now getting confusing messages.  On Prism, eTester 
> comes automatically with the precompile and they are shown that in 
> the report 1 get started files.  In my examples and on their PCs they 
> will have to have eTester as a separate cluster.   The latter are 
> described in the www page that Dave wrote, and are in my slides so I 
> can discuss it in class.
> 
> 4 -- The precompile has a different cluster structure than what 
> happens on their PCs.  It is different from what I see on the Mac and 
> on Prism if I include my own eTester; at least it did when I 
> installed and tested using eTester 2.1.2.
> 
> 5 -- I, not to mention the students, get confused when there are 
> differences between systems.  When I saw, what to me was a complex 
> collection of clusters  with about 6-8 clusters at the upper level, 
> at first I did not even understand that the students were running 
> report 1.  I thought they were running a different system that I did 
> not know about and did not understand.    All I have is base, root 
> cluster and eTester.  That is all students see in my in class demos.
> 
> 6 -- Now my discussion and slides have to present two different views 
> of the  world.  I vote that we get rid of the precompiled eTester and 
> have all systems look the same.
> 
> Cheers ... Gunnar
> 




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Etester-devel] Re: E-Tester 2.1.2

[Gunnar G. <gu...@cs...>]

Hi All,

I agree that we fix the version for etester and provide the class 
download.  Perhaps this can be done from the etester.sourceforge.net 
page that already describes etester, its use, how to download and 
install.  Perhaps a paragraph on that page can have a link to the 
"current" 3311 download.   The alternative is for us to have a 
download on our page with a link to the instructions.

I have modified the etester slides with the link to 
estester.sourceforge.net after Dave showed me the page and indicated 
it is the root of etester info.

to_print is not needed if we read only the hml output.  If we want 
terminal output then to_print is needed.  At least that is how I 
understand estester at this time.

Cheers ... Gunnar


At 11:10 AM -0400 9/10/03, Vassilios Tzerpos wrote:
>   I have to agree with Gunnar here. Taking out to_string is a bad 
>idea. You don't change the interface on your clients. You just hope 
>to convince them of the superiority of the new interface, deprecate 
>the old, but you still let them use it :) Besides, to_string is 
>quite helpful when you get started with a test harness which happens 
>a lot for 3311.
>   On the other hand, I noticed that to_string was buggy for 2.1.0, 
>so maybe it's better it's out. If that's the case, please let us 
>know, and I'm sure we'll live without it for now. Eventually, I 
>would personally like to see it back.
>   Finally, even though the other changes for 2.1.2 were good, we 
>cannot keep changing the version that is available at sourceforge, 
>if we want students to download it from there. The last thing I want 
>to do is deal with complaints that students were using the wrong 
>etester version or something like that.
>   As a result, I would rather take a version such as 2.1.2, put it 
>on the course web page, and have students download it from there. As 
>much as software is a living thing, for code that is distributed to 
>students, I would prefer something "dead" :)
>   I think the plan should be the following: Dave lets us know 
>whether to_string can come back before the end of the week working 
>correctly. If  so, make that change, call it 2.1.3 and that's what 
>we'll give to the students. If not, we'll go with 2.1.2.
>   How does it sound?
>   Bil

[Etester-devel] Re: E-Tester 2.1.2

[Gunnar G. <gu...@cs...>]

Hi Dave,

Thank you for your help.

I noticed, as you stated in my office that I was using to_html.   I 
thought some more about the program.  It turns out that my  use of 
to_print is a left over from etester 1.7.  With each version I make 
minimal changes to have a system run.  With v1.7 the output went to a 
terminal window, now it goes to an html file.   My use of to_print 
caused spurious terminal output and I could not understand why but 
since the system worked and I got the html file, I did not worry 
about it and went on to other tasks.

At a base level it was my fault in not understanding etester (I 
probably still don't), as I should not have been using to_print and 
the problem would not have come up with the dictionary system and 
other examples.

Cheers ... Gunnar


At 10:50 AM -0400 9/10/03, Dave Makalsky wrote:
>Hi Gunnar:
>
>Thank you for your continued assistance in clarifying the changes.
>
>to_html is a procedure and not a function, therefore 
>print(to_html(filename)) will not work.
>
>What you need to do is simply call to_html("filename.html")
>
>and then use etester-gui or some html browser to examine filename.html.
>
>Cheers,
>
>DM
>
>Gunnar Gotshalks wrote:
>
>>Hi Dave,
>>
>>Responses interspersed with your message.
>>
>>At 6:04 PM -0400 9/9/03, Dave Makalsky wrote:
>>
>>>E-Tester 2.1.2 has been released.
>>
>>
>>I downloaded and tried it on my dictionary system.  It failed to 
>>compile, no to_string feature, see below.
>>
>>>Changelog:
>>>
>>>- indexing clauses have been updated to reflect the current version number
>>
>>
>>Good.
>>
>>>- As per Gunnar's suggestion the folder is now named etester2.1.2 and not
>>>etester2-dev
>>
>>
>>Thank you.  It helps the user keep track of the different versions 
>>-- I have now three:
>>2.0, 2.1 and 2.1.2.  Oops, need to remove 2.1.
>>
>>>- to_string has been removed since to_html is superior ... this 
>>>will eventually
>>>   be replaced with to_xml
>>
>>
>>Thank goodness for this message as I would have been completely 
>>lost without it.   I suggest that with every new version you give a 
>>change log.  I do not believe that I am in the minority in saying 
>>that I have may other things I want to do besides spending time 
>>reverse engineering systems to find differences.
>>
>>Sorry but more negativity,  Using your statement, I replaced 
>>to_string with to_html.   The compilation failed.  I now find out 
>>that the parameters have changed.  My question, after searching for 
>>the feature (which class is it in? I assume it is in the 
>>HTML_REPORTING cluster but there are three classes tosearch).
>>
>>My point.  Why do I have to search?  The comment to_string has been 
>>replaced by to_html needs to be expanded to somelike the following.
>>
>>to_string has been replaced by to_html.  In version 2.0 the use of 
>>to_string was
>>    print(to_string)
>>The use of to_html is similar as follows
>>    print(to_html(output_file_name))
>>
>>I have not tried that.  Is that correct?  Or do I have to do more 
>>trial and error work?
>>
>>Please, when making changes for clear, unambiguous instructions for 
>>users about the changes.  The computing world, and even the 
>>technology world in general, has too many people and instances that 
>>like game playing and think that all users should spend hours 
>>experimenting with their systems when changes take place.
>>
>>Please tell me, and other users exactly what changes I need to make 
>>to have old programs work.  This is very important as I have 
>>examples for students that are "old" and on Prism they are using 
>>v2.1 or v2.1.2 so my examples all fail.  I have may other things to 
>>to besides trial and error playing with etester  (for example I 
>>have to prepare for a COSC 3401 class in 45 minutes).    I repeat 
>>such instructions, should be industry standard.
>>
>>I also note that you are planing on changing from to_html to 
>>to_xml. Thus you are expecting me and others, to edit all old 
>>programs now and again in the future.  This is not good design. 
>>The interface should be the most stable part of the system.  It is 
>>the most critical and most time consuming for user's of your system 
>>to learn and then modify.
>>
>>If you are going to change the name then change it to  to_sgml 
>>because SGML is the abstract standard that includes HTML, XML, 
>>Bookmaster, Lector, and other tagging systems.  For variations you 
>>have  
>>to_sgml_html, to_sgml_xml but these are additions to your system. 
>>Do not remove such features as that forces all clients to be edited.
>>
>>Cheers ... Gunnar

Re: [Etester-devel] Re: E-Tester 2.1.2

[Vassilios T. <bi...@cs...>]

   I have to agree with Gunnar here. Taking out to_string is a bad idea. 
You don't change the interface on your clients. You just hope to 
convince them of the superiority of the new interface, deprecate the 
old, but you still let them use it :) Besides, to_string is quite 
helpful when you get started with a test harness which happens a lot for 
3311.
   On the other hand, I noticed that to_string was buggy for 2.1.0, so 
maybe it's better it's out. If that's the case, please let us know, and 
I'm sure we'll live without it for now. Eventually, I would personally 
like to see it back.
   Finally, even though the other changes for 2.1.2 were good, we cannot 
keep changing the version that is available at sourceforge, if we want 
students to download it from there. The last thing I want to do is deal 
with complaints that students were using the wrong etester version or 
something like that.
   As a result, I would rather take a version such as 2.1.2, put it on 
the course web page, and have students download it from there. As much 
as software is a living thing, for code that is distributed to students, 
I would prefer something "dead" :)
   I think the plan should be the following: Dave lets us know whether 
to_string can come back before the end of the week working correctly. If 
  so, make that change, call it 2.1.3 and that's what we'll give to the 
students. If not, we'll go with 2.1.2.
   How does it sound?
   Bil

Gunnar Gotshalks wrote:
> Hi Dave,
> 
> Responses interspersed with your message.
> 
> At 6:04 PM -0400 9/9/03, Dave Makalsky wrote:
> 
>> E-Tester 2.1.2 has been released.
> 
> 
> I downloaded and tried it on my dictionary system.  It failed to 
> compile, no to_string feature, see below.
> 
>> Changelog:
>>
>> - indexing clauses have been updated to reflect the current version 
>> number
> 
> 
> Good.
> 
>> - As per Gunnar's suggestion the folder is now named etester2.1.2 and not
>> etester2-dev
> 
> 
> Thank you.  It helps the user keep track of the different versions -- I 
> have now three:
> 2.0, 2.1 and 2.1.2.  Oops, need to remove 2.1.
> 
>> - to_string has been removed since to_html is superior ... this will 
>> eventually
>>   be replaced with to_xml
> 
> 
> Thank goodness for this message as I would have been completely lost 
> without it.   I suggest that with every new version you give a change 
> log.  I do not believe that I am in the minority in saying that I have 
> may other things I want to do besides spending time reverse engineering 
> systems to find differences.
> 
> Sorry but more negativity,  Using your statement, I replaced to_string 
> with to_html.   The compilation failed.  I now find out that the 
> parameters have changed.  My question, after searching for the feature 
> (which class is it in? I assume it is in the HTML_REPORTING cluster but 
> there are three classes tosearch).
> 
> My point.  Why do I have to search?  The comment to_string has been 
> replaced by to_html needs to be expanded to somelike the following.
> 
> to_string has been replaced by to_html.  In version 2.0 the use of 
> to_string was
>    print(to_string)
> The use of to_html is similar as follows
>    print(to_html(output_file_name))
> 
> I have not tried that.  Is that correct?  Or do I have to do more trial 
> and error work?
> 
> Please, when making changes for clear, unambiguous instructions for 
> users about the changes.  The computing world, and even the technology 
> world in general, has too many people and instances that like game 
> playing and think that all users should spend hours experimenting with 
> their systems when changes take place.
> 
> Please tell me, and other users exactly what changes I need to make to 
> have old programs work.  This is very important as I have examples for 
> students that are "old" and on Prism they are using v2.1 or v2.1.2 so my 
> examples all fail.  I have may other things to to besides trial and 
> error playing with etester  (for example I have to prepare for a COSC 
> 3401 class in 45 minutes).    I repeat such instructions, should be 
> industry standard.
> 
> I also note that you are planing on changing from to_html to to_xml. 
> Thus you are expecting me and others, to edit all old programs now and 
> again in the future.  This is not good design.   The interface should be 
> the most stable part of the system.  It is the most critical and most 
> time consuming for user's of your system to learn and then modify.
> 
> If you are going to change the name then change it to  to_sgml because 
> SGML is the abstract standard that includes HTML, XML, Bookmaster, 
> Lector, and other tagging systems.  For variations you have   
> to_sgml_html, to_sgml_xml but these are additions to your system.  Do 
> not remove such features as that forces all clients to be edited.
> 
> Cheers ... Gunnar
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Etester-devel mailing list
> Ete...@li...
> https://lists.sourceforge.net/lists/listinfo/etester-devel
> 

[Etester-devel] Re: E-Tester 2.1.2

[Dave M. <dm...@cs...>]

Hi Gunnar:

Thank you for your continued assistance in clarifying the changes.

to_html is a procedure and not a function, therefore 
print(to_html(filename)) will not work.

What you need to do is simply call to_html("filename.html")

and then use etester-gui or some html browser to examine filename.html.

Cheers,

DM

Gunnar Gotshalks wrote:

> Hi Dave,
>
> Responses interspersed with your message.
>
> At 6:04 PM -0400 9/9/03, Dave Makalsky wrote:
>
>> E-Tester 2.1.2 has been released.
>
>
> I downloaded and tried it on my dictionary system.  It failed to 
> compile, no to_string feature, see below.
>
>> Changelog:
>>
>> - indexing clauses have been updated to reflect the current version 
>> number
>
>
> Good.
>
>> - As per Gunnar's suggestion the folder is now named etester2.1.2 and 
>> not
>> etester2-dev
>
>
> Thank you.  It helps the user keep track of the different versions -- 
> I have now three:
> 2.0, 2.1 and 2.1.2.  Oops, need to remove 2.1.
>
>> - to_string has been removed since to_html is superior ... this will 
>> eventually
>>   be replaced with to_xml
>
>
> Thank goodness for this message as I would have been completely lost 
> without it.   I suggest that with every new version you give a change 
> log.  I do not believe that I am in the minority in saying that I have 
> may other things I want to do besides spending time reverse 
> engineering systems to find differences.
>
> Sorry but more negativity,  Using your statement, I replaced to_string 
> with to_html.   The compilation failed.  I now find out that the 
> parameters have changed.  My question, after searching for the feature 
> (which class is it in? I assume it is in the HTML_REPORTING cluster 
> but there are three classes tosearch).
>
> My point.  Why do I have to search?  The comment to_string has been 
> replaced by to_html needs to be expanded to somelike the following.
>
> to_string has been replaced by to_html.  In version 2.0 the use of 
> to_string was
>    print(to_string)
> The use of to_html is similar as follows
>    print(to_html(output_file_name))
>
> I have not tried that.  Is that correct?  Or do I have to do more 
> trial and error work?
>
> Please, when making changes for clear, unambiguous instructions for 
> users about the changes.  The computing world, and even the technology 
> world in general, has too many people and instances that like game 
> playing and think that all users should spend hours experimenting with 
> their systems when changes take place.
>
> Please tell me, and other users exactly what changes I need to make to 
> have old programs work.  This is very important as I have examples for 
> students that are "old" and on Prism they are using v2.1 or v2.1.2 so 
> my examples all fail.  I have may other things to to besides trial and 
> error playing with etester  (for example I have to prepare for a COSC 
> 3401 class in 45 minutes).    I repeat such instructions, should be 
> industry standard.
>
> I also note that you are planing on changing from to_html to to_xml. 
> Thus you are expecting me and others, to edit all old programs now and 
> again in the future.  This is not good design.   The interface should 
> be the most stable part of the system.  It is the most critical and 
> most time consuming for user's of your system to learn and then modify.
>
> If you are going to change the name then change it to  to_sgml because 
> SGML is the abstract standard that includes HTML, XML, Bookmaster, 
> Lector, and other tagging systems.  For variations you have   
> to_sgml_html, to_sgml_xml but these are additions to your system.  Do 
> not remove such features as that forces all clients to be edited.
>
> Cheers ... Gunnar

[Etester-devel] Re: E-Tester 2.1.2

[Gunnar G. <gu...@cs...>]

Hi Dave,

Responses interspersed with your message.

At 6:04 PM -0400 9/9/03, Dave Makalsky wrote:
>E-Tester 2.1.2 has been released.

I downloaded and tried it on my dictionary system.  It failed to 
compile, no to_string feature, see below.

>Changelog:
>
>- indexing clauses have been updated to reflect the current version number

Good.

>- As per Gunnar's suggestion the folder is now named etester2.1.2 and not
>etester2-dev

Thank you.  It helps the user keep track of the different versions -- 
I have now three:
2.0, 2.1 and 2.1.2.  Oops, need to remove 2.1.

>- to_string has been removed since to_html is superior ... this will 
>eventually
>   be replaced with to_xml

Thank goodness for this message as I would have been completely lost 
without it.   I suggest that with every new version you give a change 
log.  I do not believe that I am in the minority in saying that I 
have may other things I want to do besides spending time reverse 
engineering systems to find differences.

Sorry but more negativity,  Using your statement, I replaced 
to_string with to_html.   The compilation failed.  I now find out 
that the parameters have changed.  My question, after searching for 
the feature (which class is it in? I assume it is in the 
HTML_REPORTING cluster but there are three classes tosearch).

My point.  Why do I have to search?  The comment to_string has been 
replaced by to_html needs to be expanded to somelike the following.

to_string has been replaced by to_html.  In version 2.0 the use of 
to_string was
    print(to_string)
The use of to_html is similar as follows
    print(to_html(output_file_name))

I have not tried that.  Is that correct?  Or do I have to do more 
trial and error work?

Please, when making changes for clear, unambiguous instructions for 
users about the changes.  The computing world, and even the 
technology world in general, has too many people and instances that 
like game playing and think that all users should spend hours 
experimenting with their systems when changes take place.

Please tell me, and other users exactly what changes I need to make 
to have old programs work.  This is very important as I have examples 
for students that are "old" and on Prism they are using v2.1 or 
v2.1.2 so my examples all fail.  I have may other things to to 
besides trial and error playing with etester  (for example I have to 
prepare for a COSC 3401 class in 45 minutes).    I repeat such 
instructions, should be industry standard.

I also note that you are planing on changing from to_html to to_xml. 
Thus you are expecting me and others, to edit all old programs now 
and again in the future.  This is not good design.   The interface 
should be the most stable part of the system.  It is the most 
critical and most time consuming for user's of your system to learn 
and then modify.

If you are going to change the name then change it to  to_sgml 
because SGML is the abstract standard that includes HTML, XML, 
Bookmaster, Lector, and other tagging systems.  For variations you 
have   to_sgml_html, to_sgml_xml but these are additions to your 
system.  Do not remove such features as that forces all clients to be 
edited.

Cheers ... Gunnar

[Etester-devel] E-Tester 2.1.2

[<dm...@cs...>]

E-Tester 2.1.2 has been released.

Changelog:

- indexing clauses have been updated to reflect the current version number
- to_string has been removed since to_html is superior ... this will eventually
  be replaced with to_xml
- As per Gunnar's suggestion the folder is now named etester2.1.2 and not
etester2-dev

I would again like to take this opportunity to apologize for the mixup regarding
the released files.  I suppose that this is a classic example of what happens
when I forget to follow the 'single choice principle'.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

RE: [Etester-devel] BUG report and suggestions for site

[Jonathan S. O. <jon...@yo...>]

> I have made the requested changes.  Please have a look at the 
> site and confirm.
> 
> http://etester.sourceforge.net/

Looks good. 

Jonathan

Re: [Etester-devel] BUG report and suggestions for site

[<dm...@cs...>]

Hi Jonathan:

I have made the requested changes.  Please have a look at the site and confirm.

http://etester.sourceforge.net/

Cheers,

DM

Quoting "Jonathan S. Ostroff" <jon...@yo...>:

> > Please have a look at the summary page available:
> > 
> > http://etester.sourceforge.net/
> > 
> > Let me know what you all think.
> 
> Dave:
> 
> I suggest you put on the main page some information about how easy it is to
> write tests once etester is installed.
> 
> See attached files.
> 
> You could write something like:
> 
> ============================
> 
> Once etester and gui is installed, tests are easy to write (e.g.
> array_test.html). There are two kinds of tests: (a) boolean test cases and
> (b) violation cases [see array_test.htm].
> 
> Make sure assertion checking id turned [see assertion_checking.png]. Make
> sure that the etester cluster is selected as a library [cluster.png]
> 
> EtesterGui displays the output as shown [see tests.htm].
> 
> You can also write test suites and use fixtures (setup/teardown).
> 
> ============================
> 
> You should also say that this has been tested at this point only for ISE
> Eiffel.
> 
> JSO
> 
> =====================Bug report=====================
> print(to_string) does not seem to work for the array_test example. The
> output printed is:
> 
> 
> ARRAY_TEST
> 
>    FAILED
>    FAILED
> 
> 0 out of 0 passed.
> 
> 




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Etester-devel] Re: Etester 2.1

[Vassilios T. <bi...@cs...>]

Dave Makalsky wrote:
> Gunnar, Bil:
> 
> thanks for pointing this out.  I had two local versions of etester on my 
> machine.  I am so sorry about this.
> 
> I have made the appropriate fix and uploaded the zip file.
> 
> Please confirm that it now works.
> 
> Hanging my head in shame,
> 
> DM

   No prob :) Seems to work fine under Windows now...
   Bil

[Etester-devel] Re: Etester 2.1

[Dave M. <dm...@cs...>]

Gunnar, Bil:

 thanks for pointing this out.  I had two local versions of etester on 
my machine.  I am so sorry about this.

I have made the appropriate fix and uploaded the zip file.

Please confirm that it now works.

Hanging my head in shame,

DM

Vassilios Tzerpos wrote:

>  The posted version of etester is indeed buggy. However, the fix is very
>easy. Just comment out the to_xml feature in TEST_SUITE and it should work.
>(at least it works fine for Report 1 code). Dave should probably post a
>fixed version asap though...
>  By the way, starting with 1.4 I believe, you can double-click on a jar
>file and it runs. Works great with etester-gui (under Windows at least :)
>  Cheers,
>  Bil
>  
>

[Etester-devel] BUG report and suggestions for site

[Jonathan S. O. <jon...@yo...>]

> Please have a look at the summary page available:
> 
> http://etester.sourceforge.net/
> 
> Let me know what you all think.

Dave:

I suggest you put on the main page some information about how easy it is to
write tests once etester is installed.

See attached files.

You could write something like:

============================

Once etester and gui is installed, tests are easy to write (e.g.
array_test.html). There are two kinds of tests: (a) boolean test cases and
(b) violation cases [see array_test.htm].

Make sure assertion checking id turned [see assertion_checking.png]. Make
sure that the etester cluster is selected as a library [cluster.png]

EtesterGui displays the output as shown [see tests.htm].

You can also write test suites and use fixtures (setup/teardown).

============================

You should also say that this has been tested at this point only for ISE
Eiffel.

JSO

=====================Bug report=====================
print(to_string) does not seem to work for the array_test example. The
output printed is:


ARRAY_TEST

   FAILED
   FAILED

0 out of 0 passed.

RE: [Etester-devel] E-Tester site

[Jonathan S. O. <jon...@yo...>]

Looks good.

One question. You write

"Launch etester-gui by typing in a console: java -jar etester-gui.jar".

Why not mention that you can right-click and say open with jawaw.

JSO

> -----Original Message-----
> From: ete...@li... 
> [mailto:ete...@li...] On Behalf 
> Of Dave Makalsky
> Sent: Friday, September 05, 2003 10:51 PM
> To: ete...@li...
> Subject: [Etester-devel] E-Tester site
> 
> 
> Hi:
> 
> Please have a look at the summary page available:
> 
> http://etester.sourceforge.net/
> 
> Let me know what you all think.
> 
> Cheers,
> 
> DM
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Etester-devel mailing list
> Ete...@li...
> https://lists.sourceforge.net/lists/listinfo/etester-devel
> 

[Etester-devel] ETester2.1-GUI

[Dave M. <dm...@cs...>]

Hi:

ETester-GUI has been updated on sourceforge to include the latest fix 
for solaris xterms.

Cheers,

DM

[Etester-devel] E-Tester site

[Dave M. <dm...@cs...>]

Hi:

Please have a look at the summary page available:

http://etester.sourceforge.net/

Let me know what you all think.

Cheers,

DM

[Etester-devel] Re: Etester v2.1 on red/ Friday

[Dave M. <dm...@cs...>]

I will throw it into the next version

- DM
Jason Keltz wrote:

>It would be good to include a "quit" button since most of our students use
>twm.
>
>  
>

RE: [Etester-devel] Etester 2.1 update

[Jonathan S. O. <jon...@yo...>]

> Please do a cvs update.  I believe the issue is fixed.

Working fine now.

JSO

Re: [Etester-devel] Etester 2.1 update

[Dave M. <dm...@cs...>]

Hi:

Please do a cvs update.  I believe the issue is fixed.

Cheers,

DM

Jonathan S. Ostroff wrote:

>The little test case below seems to run fine.
>
>The only problem I have seen is the printout for a violation case that fails
>to fail!. With that fixed we should be ready to roll.
>
>Good job.
>
>Jonathan
>
>=======
>
>class
>	TEST
>inherit
>	UNIT_TEST
>		redefine setup, teardown end
>creation
>	make
>feature
>	
>	make is
>		do
>			make_test
>			add_boolean_case (agent test1)
>			add_boolean_case (agent test2)
>			add_violation_case (agent test3)
>			add_boolean_case (agent test4)
>			add_boolean_case (agent test5)
>			to_html ("tests.htm")
>		end
>		
>feature -- cases
>	test1: BOOLEAN is
>		local
>			a: ARRAY[INTEGER]
>		do
>			comment("test1")
>			a := <<1, 2, 3, 4, 5 >>
>			Result := a.count = 5 and a.item(5) = 5
>		end
>		
>	test2: BOOLEAN is
>		local
>			a: ARRAY[INTEGER]
>		do
>			comment("test2")
>			a := <<1, 2, 3, 4, 5 >>
>			Result := a.count = 5 and a.item(3) = 3
>		end
>		
>	test3 is
>		local
>			a: ARRAY[INTEGER]
>			b: BOOLEAN
>		do
>			comment("test3")
>			a := <<1, 2, 3, 4, 5 >>
>			b := a.count = 5 and a.item(6) = 3
>		end
>		
>	test4: BOOLEAN is
>		do
>			comment("test4")
>			Result := c.count = 5 and c.item(3) = 3
>			c.force(6,6)
>		end
>		
>	test5: BOOLEAN is
>		do
>			comment("test5")
>			Result := c.count = 5 and c.item(3) = 3 and d = 1
>			-- d = 6 without teardown
>		end
>
>
>feature -- fixture
> 	c: ARRAY[INTEGER]
> 	d: INTEGER
> 	
> 	setup is
> 		do
> 			c := <<1, 2, 3, 4, 5 >>
> 			d := d + 1
> 		end
> 		
> 	teardown is
> 		do
> 			d := 0
> 		end
> 		
> 		
>
>end -- class TEST
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Etester-devel mailing list
>Ete...@li...
>https://lists.sourceforge.net/lists/listinfo/etester-devel
>  
>

RE: [Etester-devel] Etester 2.1 update

[Jonathan S. O. <jon...@yo...>]

The little test case below seems to run fine.

The only problem I have seen is the printout for a violation case that =
fails
to fail!. With that fixed we should be ready to roll.

Good job.

Jonathan

=3D=3D=3D=3D=3D=3D=3D

class
	TEST
inherit
	UNIT_TEST
		redefine setup, teardown end
creation
	make
feature
=09
	make is
		do
			make_test
			add_boolean_case (agent test1)
			add_boolean_case (agent test2)
			add_violation_case (agent test3)
			add_boolean_case (agent test4)
			add_boolean_case (agent test5)
			to_html ("tests.htm")
		end
	=09
feature -- cases
	test1: BOOLEAN is
		local
			a: ARRAY[INTEGER]
		do
			comment("test1")
			a :=3D <<1, 2, 3, 4, 5 >>
			Result :=3D a.count =3D 5 and a.item(5) =3D 5
		end
	=09
	test2: BOOLEAN is
		local
			a: ARRAY[INTEGER]
		do
			comment("test2")
			a :=3D <<1, 2, 3, 4, 5 >>
			Result :=3D a.count =3D 5 and a.item(3) =3D 3
		end
	=09
	test3 is
		local
			a: ARRAY[INTEGER]
			b: BOOLEAN
		do
			comment("test3")
			a :=3D <<1, 2, 3, 4, 5 >>
			b :=3D a.count =3D 5 and a.item(6) =3D 3
		end
	=09
	test4: BOOLEAN is
		do
			comment("test4")
			Result :=3D c.count =3D 5 and c.item(3) =3D 3
			c.force(6,6)
		end
	=09
	test5: BOOLEAN is
		do
			comment("test5")
			Result :=3D c.count =3D 5 and c.item(3) =3D 3 and d =3D 1
			-- d =3D 6 without teardown
		end


feature -- fixture
 	c: ARRAY[INTEGER]
 	d: INTEGER
 =09
 	setup is
 		do
 			c :=3D <<1, 2, 3, 4, 5 >>
 			d :=3D d + 1
 		end
 	=09
 	teardown is
 		do
 			d :=3D 0
 		end
 	=09
 	=09

end -- class TEST

Re: [Etester-devel] Etester 2.1 update

[Dave M. <dm...@cs...>]

As a result of Jonathan's strong urging, I have included to_html in 
UNIT_TEST.

Also,  setup and teardown are fully implemented.

Please do a CVS update to try out the latest code and let me know if I 
can release as 2.1

Cheers,

DM

Jonathan S. Ostroff wrote:

>>I have taken out to_html in UNIT_TEST, as I believe it should 
>>be mandatory to
>>create a TEST_SUITE to run the tests.  To that effect, I have 
>>created a
>>TEST_SUITE generator which will automatically create a SUITE class.
>>    
>>
>
>Does the generator work from the etestergui? If not, then we are
>transgressing Occam's razor -- do not multiply entities unnecessarily.
>
>I very strongly urge you not to take it out. 
>
>By having it in, we retain the ability to write a simple test with one class
>without all sorts of infrastructure and generators.
>
>Regards ... Jonathan
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Etester-devel mailing list
>Ete...@li...
>https://lists.sourceforge.net/lists/listinfo/etester-devel
>  
>

RE: [Etester-devel] Etester 2.1 update

[Jonathan S. O. <jon...@yo...>]

> I have taken out to_html in UNIT_TEST, as I believe it should=20
> be mandatory to
> create a TEST_SUITE to run the tests.  To that effect, I have=20
> created a
> TEST_SUITE generator which will automatically create a SUITE class.

Does the generator work from the etestergui? If not, then we are
transgressing Occam's razor -- do not multiply entities unnecessarily.

I very strongly urge you not to take it out.=20

By having it in, we retain the ability to write a simple test with one =
class
without all sorts of infrastructure and generators.

Regards ... Jonathan

[Etester-devel] Etester 2.1 update

[<dm...@cs...>]

ETester 2.1 is nearly complete.  

Test Fixtures
-------------

Setup and Teardown have been fully implemented and are quite easy to use. 
Subclasses of UNIT_TEST can simply redefine setup and teardown (currently simple
skip procedures) to create a sequence of events that will be executed before and
after every test case.  See http://junit.sourceforge.net/doc/faq/faq.htm#tests_2
for test fixture details.

Large Font Support
------------------

After wrestling with the to_html functionality to extend it to support large
font, I have given up on this feature until I implement to_xml.  Then, html
output will become obsolete as we can use XSLT, or native GUI components to
represent the data as we see fit.  The GOBO xml parser will be used to implement
this functionality.  This may cause some complexity in ACE files, though. 
Feedback would be appreciated.

to_html in UNIT_TEST
--------------------

I have taken out to_html in UNIT_TEST, as I believe it should be mandatory to
create a TEST_SUITE to run the tests.  To that effect, I have created a
TEST_SUITE generator which will automatically create a SUITE class.

I will update the cvs code tonight and hopefully we can test out these changes
before I release them as 2.1

Cheers,

DM

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

RE: [Etester-devel] Too much work in make of test_suite

[Jonathan S. O. <jon...@yo...>]

>    Looks like an unnecessary restriction to me. For example, 
> what about 
> test fixtures? I understand that etester does not support 
> test fixtures 
> at the moment (I'd be happy for a correction if I'm wrong 
> about this), 
> but it looks like a feature you might want to add (it sure would have 
> come in handy last winter). In that case, you might want to 
> create with 
> make or make_with_fixture (sure you can make_with_fixture all 
> the time 
> and have an empty fixture but that's stretching things a 
> bit). And what 
> if you have more than one fixtures?
>    Comments always welcome.
>    Bil

It does support set_up and tear_down but Dave is re-implementing.

JSO