This is a multi-part message in MIME format. ------ extPart_000_0007_01C1E933.B921D290 Content-Type: text/plain; charset s-ascii" Content-Transfer-Encoding: 7bit Brian: See comments in red... Thank you for your comments. I will think about them as I write the next draft. Other comments so far, from both Rubyists and Ruby novices, make me think I should leave the level of Ruby detail about the same. As far as the testing topics go, you'll have helped me be more precise about my wording. But I don't yield on my claim that the combination of automation through a scripting interface and manual exploratory testing is a better default choice than automation with a GUI testing tool. That's not a topic for this list, though. My only point is that you cannot use a script interface that is itself untested to test functionality that that also happens to be accessible through the GUI. You must test the GUI independently in any case (if only to prove that it actually accesses that lower-level functionality properly); whether it's feasible to test every aspect of the GUI with a given automated test tool in the circumstance that there are custom object headaches to contend with is not a factor in the need to test the GUI somehow, separately from the scripting interface. It must be done, manually if necessary. That was the gist of my concern with your approach. Now having said that I do think there is value in testing the interface itself through scripting. Just not as a substitue for GUI testing, however you choose to do it. In other words, a professional test engineer cannot "shun" the GUI, however much of a pain in the butt it is to test, with or without an automated test tool. You *can* however supplement GUI testing with testing of more programmatically direct means of accessing application functionality, i.e., through a script interface (if the application even supports such an interface). This is the first time I've used win32ole and only the second time I've talked programmatically to Word. Do you wan't the truth? It kinda shows... :( I'd appreciate suggestions for improvement, keeping in mind that I'm writing for a novice audience. 4 points: 1. I'm sorry that came out as badly as it did. I apologize for the tone. 2. There weren't any specifics so I could not give any suggestions one way or the other. There was no code in your snippet that I could comment on, and your description of OLE as a logical "or" to COM suggested that you yourself did not understand that OLE is a technology built on top of COM (like other technologies, such as structured storage, ADO, and so on), not just another name for it. 3. It may be just a matter of imprecise wording, but given your insistence that you are speaking to a novice audience, I caution you not to add to any confusion your audience might be experiencing by attempting to protect them unduly from the rigors of reading more precise explanations. On my experience, having gone from "novice" to "experienced" in numerous technologies, I always appreciate authors who, rather than spare me difficult explanations or sugar coat them with "kinder, gentler" ambiguities, engage in them with clarity of thought and a flare for analogy, metaphor and lots of handy sample code. 4. Word is not a good example for your article. For one thing, it's already a finished commercial application. You are saying that a tester should use the script interface of an application instead of banging away at the GUI with a hard-to-configure test tool. Fine: Provide an application (for download), even a simple one, with a GUI and a script interface, that is ready to be tested (but not yet deployed). Provide a GUI script that blows up for some reason, and a Ruby script that calls the COM interface instead and actually finds a bug. Although contrived, it would at least provide prima facie evidence that the thesis is worthy of further investigation. Just automating Word using win32ole proves nothing about your contention. I hope that is more helpful. :) -- Bob. -- "Act always so as to increase the number of choices." -- Heinz von Foerster ------ extPart_000_0007_01C1E933.B921D290 Content-Type: text/html; charset s-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=us-ascii"> <META content="MSHTML 6.00.2462.0" name=GENERATOR></HEAD> <BODY> <DIV><SPAN class=458421919-21042002></SPAN><FONT color=#ff0000><FONT ace=Arial><FONT size=2>B<SPAN class=458421919-21042002>rian:</SPAN><SPAN class=458421919-21042002> </SPAN></FONT></FONT><BR><SPAN class=458421919-21042002><FONT face=Arial size=2> </FONT></SPAN></FONT></DIV> <DIV><SPAN class=458421919-21042002><FONT face=Arial color=#ff0000 size=2>See comments in red...</FONT> </SPAN></DIV> <DIV><BR>Thank you for your comments. I will think about them as I write the next draft. Other comments so far, from both Rubyists and Ruby novices, make me think I should leave the level of Ruby detail about the same. <BR><BR>As far as the testing topics go, you'll have helped me be more precise about my wording. But I don't yield on my claim that the combination of automation through a scripting interface and manual exploratory testing is a better default choice than automation with a GUI testing tool. That's not a topic for this list, though.<SPAN class=458421919-21042002><FONT face=Arial color=#0000ff size=2> </FONT></SPAN></DIV> <DIV><SPAN class=458421919-21042002></SPAN> </DIV> <DIV><SPAN class=458421919-21042002><FONT face=Arial color=#ff0000 size=2>My only point is that you cannot use a script interface that is itself untested to test functionality that that also happens to be accessible through the GUI. You must test the GUI independently in any case (if only to prove that it actually accesses that lower-level functionality properly); whether it's feasible to test every aspect of the GUI with a given automated test tool in the circumstance that there are custom object headaches to contend with is not a factor in the need to test the GUI somehow, separately from the scripting interface. It must be done, manually if necessary. That was the gist of my concern with your approach. Now having said that I do think there is value in testing the interface itself through scripting.</FONT> <FONT face=Arial color=#ff0000 size=2>Just not as a substitue for GUI testing, however you choose to do it.</FONT></SPAN></DIV> <DIV><SPAN class=458421919-21042002><FONT face=Arial color=#ff0000 ize=2></FONT></SPAN> </DIV> <DIV><SPAN class=458421919-21042002><FONT face=Arial color=#ff0000 size=2>In other words, a professional test engineer cannot "shun" the GUI, however much of a pain in the butt it is to test, with or without an automated test tool. You *can* however supplement GUI testing with testing of more programmatically direct means of accessing application functionality, i.e., through a script interface (if the application even supports such an interface).</FONT></SPAN></DIV> <BLOCKQUOTE class=cite cite="" type="cite"> <DIV> This is the first time I've used win32ole and only the second time I've talked programmatically to Word. <FONT face=arial color=#0000ff size=2></FONT><BR><BR><FONT face=arial color=#0000ff size=2>Do you wan't the truth? It kinda shows... :(</FONT><BR> <SPAN class=458421919-21042002><FONT face=Arial color=#0000ff size=2> </FONT></SPAN></DIV> <DIV><SPAN class=458421919-21042002> </SPAN><BR>I'd appreciate suggestions for improvement, keeping in mind that I'm writing for a novice audience.<SPAN class=458421919-21042002><FONT face=Arial color=#0000ff size=2> </FONT></SPAN></DIV></BLOCKQUOTE> <DIV><SPAN class=458421919-21042002><FONT face=Arial color=#ff0000 ize=2>4 points:</FONT></SPAN></DIV> <DIV><SPAN class=458421919-21042002><FONT color=#ff0000></FONT></SPAN> </DIV> <DIV><SPAN class=458421919-21042002><FONT face=Arial color=#ff0000 size=2>1. I'm sorry that came out as badly as it did. I apologize for the tone.</FONT></SPAN></DIV> <DIV><FONT color=#ff0000><SPAN class=458421919-21042002><FONT face=Arial size=2>2. There weren't any specifics </FONT><FONT face=Arial size=2>so I could not give any suggestions one way or the other. There was no code in your snippet that I could comment on, and your description of OLE as a logical "or" to COM suggested that you yourself did not understand that OLE is a echnology built on top of COM (like other technologies, such as structured storage, ADO, and so on), not just another name for it. </FONT></SPAN></FONT></DIV> <DIV><FONT face=Arial color=#ff0000 size=2><SPAN class=458421919-21042002>3. It may be just a matter of imprecise wording, but given your insistence that you are speaking to a novice audience, I caution you not to add to any confusion your audience might be experiencing by attempting to protect them unduly from the rigors of reading more precise explanations. On my experience, having gone from "novice" to "experienced" in numerous technologies, I always appreciate authors who, rather than spare me difficult explanations or sugar coat them with "kinder, gentler" ambiguities, engage in them with clarity of thought and a flare for analogy, metaphor and lots of handy sample code.</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#ff0000 size=2><SPAN class=458421919-21042002>4. Word is not a good example for your article. For one thing, it's already a finished commercial application. You are saying that a tester should use the script interface of an application instead of banging away at the GUI with a hard-to-configure test tool. Fine: Provide an application (for download), even a simple one, with a GUI and a script interface, that is ready to be tested (but not yet deployed). Provide a GUI script that blows up for some reason, and a Ruby script that calls the COM interface instead and actually finds a bug. Although contrived, it would at least provide prima facie evidence that the thesis is worthy of further investigation. Just automating Word using win32ole proves nothing about your contention.</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#ff0000 size=2><SPAN class=458421919-21042002></SPAN></FONT> </DIV> <DIV><FONT face=Arial color=#ff0000 size=2><SPAN class=458421919-21042002>I hope that is more helpful. :)</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#ff0000 size=2><SPAN class=458421919-21042002></SPAN></FONT> </DIV> <DIV><FONT face=Arial color=#ff0000 size=2><SPAN class=458421919-21042002>-- Bob.</SPAN></FONT></DIV> <DIV>--</DIV> <DIV>"Act always so as to increase the number of choices." -- Heinz von Foerster</DIV></BODY></HTML> ------ extPart_000_0007_01C1E933.B921D290--