From: ccalvert <cca...@pa...> - 2003-01-19 07:01:13
|
Hi all. I've been using your tool some the last few days. It's great! I'm just getting into the GuiTesting part of it. Don't know the code base very well yet, but it appears that you are not checking for Control key presses in the EnterKeyInto method of TGuiTestCase from GuiTesting.pas. Here is a cheap and quick fix, where the first dozen or so lines provide context: procedure TGUITestCase.EnterKeyInto(Control: TControl; Key: Word; const ShiftState: TShiftState); {$IFDEF DUNIT_CLX} var E: QKeyEventH; S: WideString; state: integer; {$ENDIF} begin Assert(Control <> nil, 'No control'); Control := FindParentWinControl(Control); if Control <> nil then begin {$IFDEF DUNIT_CLX} if Key <= 255 then S := Char(Key) else S := ''; if ssAlt in ShiftState then State := integer(ButtonState_AltButton) else if ssCtrl in ShiftState then // <--- The fix State := Integer(ButtonState_ControlButton) // <--- The fix else State := 0; I suppose one should check to see if both Alt and Control are pressed? At any rate, this code solved my problem. While I'm here, I seem to be having some trouble figuring out what to do if I'm in a form, and I pop up a modal dialog. How do I enter key presses into that dialog? I'm hacking around it fairly easily for now just by modifying my own code, but would like to know if there is a standard DUnit way to handle modal dialogs which appear on top of the form I am testing. - Charlie Calvert |
From: <jua...@ca...> - 2003-01-20 13:23:24
|
Hi Charlie, > if ssAlt in ShiftState then > State := integer(ButtonState_AltButton) > else if ssCtrl in ShiftState then // <--- The fix > State := Integer(ButtonState_ControlButton) // <--- The Thanks for the fix. I'll check the API to see if it accepts more than one ButtonState flag. If so, then maybe the fix should be: if ssAlt in ShiftState then State := State or integer(ButtonState_AltButton); if ssCtrl in ShiftState then State := State or Integer(ButtonState_ControlButton); //... > While I'm here, I seem to be having some trouble figuring out > what to do > if I'm in a form, and I pop up a modal dialog. There's currently no way to test a modal dialog. What I have done in the past is test those dialogs by launching them modelessly. The problem is that a modal dialog captures the running thread, so the testing module would have to run on a different thread and sync with the VCL or use PostMessage to inject events into the dialog's event queue. AFAIK, no one has looked into how to do that. Regards, Juanco |
From: Krzysztof G. <krz...@ya...> - 2003-01-22 00:05:04
|
--- ccalvert <cca...@pa...> wrote: > Hi all. > > I've been using your tool some the last few days. > It's great! > > I'm just getting into the GuiTesting part of it. > Don't know the code > base very well yet, but it appears that you are not > checking for Control > key presses in the EnterKeyInto method of > TGuiTestCase from > GuiTesting.pas. Here is a cheap and quick fix, where > the first dozen or > so lines provide context: > > procedure TGUITestCase.EnterKeyInto(Control: > TControl; Key: Word; const > ShiftState: TShiftState); > {$IFDEF DUNIT_CLX} > var > E: QKeyEventH; > S: WideString; > state: integer; > {$ENDIF} > begin > Assert(Control <> nil, 'No control'); > Control := FindParentWinControl(Control); > if Control <> nil then > begin > {$IFDEF DUNIT_CLX} > if Key <= 255 then > S := Char(Key) > else > S := ''; > if ssAlt in ShiftState then > State := integer(ButtonState_AltButton) > else if ssCtrl in ShiftState then > // <--- The fix > State := Integer(ButtonState_ControlButton) > // <--- The fix > else > State := 0; > > I suppose one should check to see if both Alt and > Control are pressed? > At any rate, this code solved my problem. > > While I'm here, I seem to be having some trouble > figuring out what to do > if I'm in a form, and I pop up a modal dialog. How > do I enter key > presses into that dialog? I'm hacking around it > fairly easily for now > just by modifying my own code, but would like to > know if there is a > standard DUnit way to handle modal dialogs which > appear on top of the > form I am testing. > > - Charlie Calvert > > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide > from Thawte > are you planning your Web Server Security? Click > here to get a FREE > Thawte SSL guide and find the answers to all your > SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Dunit-interest mailing list > Dun...@li... > https://lists.sourceforge.net/lists/listinfo/dunit-interest __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
From: Krzysztof G. <krz...@ya...> - 2003-01-22 00:14:19
|
I have to admit I the authorof this buggy code, for my excuse I hardly expect anyone using it. Great thanks for the fix > procedure TGUITestCase.EnterKeyInto(Control: > TControl; Key: Word; const > ShiftState: TShiftState); > {$IFDEF DUNIT_CLX} > var > E: QKeyEventH; > S: WideString; > state: integer; > {$ENDIF} > begin > Assert(Control <> nil, 'No control'); > Control := FindParentWinControl(Control); > if Control <> nil then > begin > {$IFDEF DUNIT_CLX} > if Key <= 255 then > S := Char(Key) > else > S := ''; > if ssAlt in ShiftState then > State := integer(ButtonState_AltButton) > else if ssCtrl in ShiftState then > // <--- The fix > State := Integer(ButtonState_ControlButton) > // <--- The fix > else > State := 0; > > I suppose one should check to see if both Alt and > Control are pressed? > At any rate, this code solved my problem. Kris __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
From: ccalvert <cca...@pa...> - 2003-01-22 02:58:16
|
No apologies needed. You helped write the code. For that, we all owe you a note of thanks. - Charlie Krzysztof Golko wrote: >I have to admit I the authorof this buggy code, for my >excuse I hardly expect anyone using it. > >Great thanks for the fix > > |
From: Krzysztof G. <krz...@ya...> - 2003-01-23 16:42:22
|
Charlie, Just curious, are using it with Kylix or Delphi VisualCLX? Kris --- ccalvert <cca...@pa...> wrote: > No apologies needed. You helped write the code. For > that, we all owe you > a note of thanks. > > - Charlie > > Krzysztof Golko wrote: > > >I have to admit I the authorof this buggy code, for > my > >excuse I hardly expect anyone using it. > > > >Great thanks for the fix > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for > Techies! > Can't afford IT training? All 2003 ictp students > receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, > Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > Dunit-interest mailing list > Dun...@li... > https://lists.sourceforge.net/lists/listinfo/dunit-interest __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
From: ccalvert <cca...@pa...> - 2003-01-24 07:35:40
|
Kris, My program runs on both Linux and Windows. The testing that I was doing was in Windows, using CLX. Pretty much all my Delphi programming at this point is CLX based, but I'm really interested in cross-platform development, so I'm using CLX not because it runs in Linux, but because it runs on both Linux and Windows. I'm also testing some under Linux, but right now I'm finding that I'm having focus problems when testing dunit GUI based apps on Linux. Sometimes the DUnit Form itself pops to the surface, partially hiding my app. The same thing does not happen with the same code on Windows. To tell you the truth, I have not wrestled with this problem at all, since it's simpler to do my DUnit testing on Windows that to try to figure out what is wrong. So my app runs on both platforms, but I do most of my dunit testing on Windows. - Charlie Krzysztof Golko wrote: >Charlie, > >Just curious, are using it with Kylix or Delphi >VisualCLX? > >Kris > >--- ccalvert <cca...@pa...> wrote: > > >>No apologies needed. You helped write the code. For >>that, we all owe you >>a note of thanks. >> >>- Charlie >> >>Krzysztof Golko wrote: >> >> >> >>>I have to admit I the authorof this buggy code, for >>> >>> >>my >> >> >>>excuse I hardly expect anyone using it. >>> >>>Great thanks for the fix >>> >>> >>> >>> >> >> >> >> >> >------------------------------------------------------- > > >>This SF.net email is sponsored by: Scholarships for >>Techies! >>Can't afford IT training? All 2003 ictp students >>receive scholarships. >>Get hands-on training in Microsoft, Cisco, Sun, >>Linux/UNIX, and more. >>www.ictp.com/training/sourceforge.asp >>_______________________________________________ >>Dunit-interest mailing list >>Dun...@li... >> >> >> >https://lists.sourceforge.net/lists/listinfo/dunit-interest > > >__________________________________________________ >Do you Yahoo!? >Yahoo! Mail Plus - Powerful. Affordable. Sign up now. >http://mailplus.yahoo.com > > >------------------------------------------------------- >This SF.NET email is sponsored by: >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! >http://www.vasoftware.com >_______________________________________________ >Dunit-interest mailing list >Dun...@li... >https://lists.sourceforge.net/lists/listinfo/dunit-interest > > > |
From: <jua...@ca...> - 2003-02-04 04:08:03
|
Charlie, > So my app runs on both platforms, but I do most of my > dunit testing on Windows. There haven't been as many Kylix users as there's been Delphi users around. I personally have yet to go beyond simple tests with Kylix. That may be why the Kylix GUI testing is unstable. Delphi-DUnit has had an intensive field test. Regards, Juanco |
From: ccalvert <cca...@pa...> - 2003-02-04 06:47:41
|
> > >There haven't been as many Kylix users as there's been Delphi users >around. I personally have yet to go beyond simple tests with Kylix. That >may be why the Kylix GUI testing is unstable. Delphi-DUnit has had an >intensive field test. > I more than understand. There are few people in the world more conscious of what's happened in the Kylix world than me. Perhaps I'll find some time to work with Kylix dunit more, but for now I'll probably continue doing most of my testing on Windows. It seems like I spend most of my time in Linux these days, but I'm used to switching over to Windows for some tasks. Please don't take any of my comments as a complaint. I'm a big fan of dunit, and I think it's a great tool. These days I use it quite a bit. - Charlie |
From: Jon S. <jo...@mi...> - 2003-02-04 20:38:26
|
Charlie Calvert wrote: > There are few people in the world more conscious > of what's happened in the Kylix world than me. I'll claim peer status, here. ;-) > Please don't take any of my comments as a complaint. I'm a big fan of > dunit, and I think it's a great tool. These days I use it quite a bit. I like dunit ... but I like Nunit a whole lot more. Seriously nice the way it can extract tests from an executable, so you don't have to separate the test-running exe from the 'real' exe. It also makes it a LOT easier to test private and protected features. I keep MEANING to try Nunit with dccil ... has anyone here done that yet? -- Consulting & contract programming http://www.midnightbeach.com My Kylix book http://www.midnightbeach.com/kylix Homeschool resources http://www.midnightbeach.com/hs |
From: Uberto B. <ub...@ub...> - 2003-02-05 08:38:36
|
>> Please don't take any of my comments as a complaint. I'm a big fan of >> dunit, and I think it's a great tool. These days I use it quite a bit. JS> I like dunit ... but I like Nunit a whole lot more. Seriously nice the I've used Nunit only when it was very rough (.NET beta 2). Apart from .NET features (attributes, introspection, etc.) do you think the design of Dunit can "borrow" something from Nunit? JS> way it can extract tests from an executable, so you don't have to JS> separate the test-running exe from the 'real' exe. It also makes it a JS> LOT easier to test private and protected features. I like to have unit tests separated from "real exe", but I'd like to test my exe too (functionality tests). Can you explain better? Ciao Uberto mailto:ub...@ub... |
From: Jon S. <jo...@mi...> - 2003-02-05 22:01:40
|
Uberto Barbini wrote: > JS> I like dunit ... but I like Nunit a whole lot more. Seriously nice the > > I've used Nunit only when it was very rough (.NET beta 2). > Apart from .NET features (attributes, introspection, etc.) do you > think the design of Dunit can "borrow" something from Nunit? I don't know what version you were using then, but they did a pretty comprehensive redesign for Nunit 2. Nunit 1 was pretty much a Junit port and thus, I assume, much like Dunit. In Nunit 2, they use [TestFixture] and [Test] attributes: any public class with [TestFixture] attribute and a public parameter-less constructor can hold tests. Any public void parameter-less procedure, with a [Test] attribute, in a [TestFixture] class is a test. No need for magic names or inheritance from special classes. You compile and run your executable with tests in it, and test it that way. The Nunit test harness uses reflection to find all the [Test] functions in [TestFixture] classes and run them. It picks up on changes automatically; if you compile new tests into the exexcutable, the test tree in the GUI version reflects it before you even re-run your tests. It's all quite slick (although the GUI is sorta clunky) but I don't know what Dunit can borrow from unless/until attributes make their way into the Classic Delphis. Even then, Delphi's smart linking may bollox things up. > I like to have unit tests separated from "real exe", but I'd like to > test my exe too (functionality tests). > Can you explain better? With Dunit, I always end up with a unit that has actual code, and a unit that contains the tests, which is slightly cumbersome. I also have to build two independent projects (albeit they can live in the same project group) and toggle between running the actual program and running the test suite. With Nunit, the [Test] functions live in the class they test, which makes it possible to test private and protected features. (Yes, it's the public features that matter, but being able to test the private and protected features as you build functionality is very nice.) With Nunit, the test harness stays up all day long, and refreshes itself every time I recompile. I can run the executable from VS, or Alt+Tab to the test harness to run the tests. (I do that about just about every time I compile.) -- Consulting & contract programming http://www.midnightbeach.com My Kylix book http://www.midnightbeach.com/kylix Homeschool resources http://www.midnightbeach.com/hs |
From: Chris M. <ch...@cl...> - 2003-02-06 13:31:36
|
> It's all quite slick (although the GUI is sorta clunky) but I don't > know what Dunit can borrow from unless/until attributes make their way > into the Classic Delphis. Even then, Delphi's smart linking may bollox > things up. > With Nunit, the test harness stays up all day long, and refreshes > itself every time I recompile. This is definitely a nice bit, except I have to get out of the habit of automatically closing the NUnit GUI Runner before heading back to the IDE :) One thing that has been discussed before, and possibly in the past someone even had a working solution, is the ability to dynamically load a .dll and/or a .bpl into the runner, and then having the runner discover the tests inside and add them to the tree view. To be able to do what NUnit does, wouldn't Delphi need to be able to recompile a dll/bpl while it was being executed? and it can't do that, IIRC, right? I guess that's one special bit about .Net and how it loads assemblies. > With Nunit, the [Test] functions live in the class they test, which > makes it possible to test private and protected features. (Yes, it's > the public features that matter, but being able to test the private > and protected features as you build functionality is very nice.) More and more I just make almost everything public in my classes -- and refactoring out classes from the bits that are mostly protected/private -- but this is obviously a preference thing. Another preference thing is shipping test code with the production code. Seems in most cases my test code is up to 2 or 3 times the size of the production code. Including tests with the prod code in .Net means your shipping all of it, so I still prefer to have separate test assemblies. Of course, the .Net runtime is 15MB, so what's the big deal if your assemblies are a little bigger :) Chris http://clabs.org |
From: Uberto B. <ub...@ub...> - 2003-02-06 18:46:58
|
CM> One thing that has been discussed before, and possibly in the past someone CM> even had a working solution, is the ability to dynamically load a .dll CM> and/or a .bpl into the runner, and then having the runner discover the tests CM> inside and add them to the tree view. It shouldn't be hard to implement, but what's the point? You have to compile the bpl/dll every time but you cannot debug tests, well it'd be more difficult. IMHO a more interesting idea is compile the testrunner in a component and put it on your form to test it. Somehow you could took it off in the production exe. CM> Another preference thing is shipping test code with the production code. CM> Seems in most cases my test code is up to 2 or 3 times the size of the CM> production code. Including tests with the prod code in .Net means your CM> shipping all of it, so I still prefer to have separate test assemblies. Of CM> course, the .Net runtime is 15MB, so what's the big deal if your assemblies CM> are a little bigger :) ;))) Apart from the dimension issue, the way I use tests I prefear keep them separated from my exe. Ciao Uberto mailto:ub...@ub... |
From: Chris M. <ch...@cl...> - 2003-02-06 18:58:48
|
> It shouldn't be hard to implement, but what's the point? > You have to compile the bpl/dll every time but you cannot debug tests, > well it'd be more difficult. That's a good point in favor of DUnit. Using NUnit, when I want to debug in the IDE, I have to attach to the process in the IDE first. Now, if (and maybe there's an IDE macro or somesuch) this was a one-step task, no big deal -- but at the moment it requires navigating about 3 dialog boxes to do it. Chris http://clabs.org |
From: <jua...@ca...> - 2003-02-07 02:44:08
|
Chris, > One thing that has been discussed before, and possibly in the > past someone even had a working solution, is the ability to > dynamically load a .dll and/or a .bpl into the runner, and > then having the runner discover the tests inside and add them > to the tree view. That is working already. It is what WANT uses for the <dunit> task. The tests loaded are the ones indicated by the DLL, though. There's no discovery process. Also, the current version requires short strings in test dlls. I did that to keep away from the borland memory manager dll, but I now think it was the wrong decission. > > With Nunit, the [Test] functions live in the class they test, which > > makes it possible to test private and protected features. There are several ways to work around that. One is to include the test classes with the main units. The other is to crack classes open to acces the protected features. type TCrackedClass = class(OtherUnit.MyClass); Juanco |
From: <jua...@ca...> - 2003-02-07 02:44:08
|
Jon, > I like dunit ... but I like Nunit a whole lot more. Seriously > nice the way it can extract tests from an executable, so you > don't have to separate the test-running exe from the 'real' > exe. It also makes it a LOT easier to test private and > protected features. With DUnit you can have your test cases in the same units as the tested code. Take a look at the examples\structure\sameunit directory. Juanco |
From: <jua...@ca...> - 2003-01-25 02:54:19
|
Kris, > I have to admit I the authorof this buggy code, for my > excuse I hardly expect anyone using it. Aha!!! Could you please check Charlie's fix and see if an "or" of the flags is appropiate in this case? Regards, Juanco |
From: Krzysztof G. <krz...@ya...> - 2003-01-25 14:40:39
|
--- Juancarlo_Añez <jua...@ca...> wrote: > Kris, > > > I have to admit I the authorof this buggy code, > for my > > excuse I hardly expect anyone using it. > > Aha!!! VCL version doesn't look like overworked either. :) > Could you please check Charlie's fix and see if an > "or" of the flags is > appropiate in this case? I think you're right, I propose to do it this way. State := 0; if ssAlt in ShiftState then State := integer(ButtonState_AltButton); if ssCtrl in ShiftState then State := State or Integer(ButtonState_ControlButton); if ssShift in ShiftState then State := State or Integer(ButtonState_ShiftButton); Kris __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
From: <jua...@ca...> - 2003-01-26 15:16:34
|
Kris, What do the docs say? Juanco > -----Original Message----- > From: dun...@li... > [mailto:dun...@li...] On Behalf > Of Krzysztof Golko > Sent: Saturday, January 25, 2003 10:41 AM > To: dun...@li... > Subject: RE: [DUnit-interest] GuiTesting proposed fix, > question about dialogs > I think you're right, I propose to do it this way. > > State := 0; > if ssAlt in ShiftState then > State := integer(ButtonState_AltButton); > if ssCtrl in ShiftState then > State := State or > Integer(ButtonState_ControlButton); > if ssShift in ShiftState then > State := State or Integer(ButtonState_ShiftButton); > > Kris |