Re: [TFUI] Testing WinForms

Hi again,

On Fri, 6 Jan 2006 09:39:05 +0100, Stefan Lieser <[email protected]>  
wrote:

> Hi Dan,
>
>> In my opinion testing if the text reaches the controller, after being
>> entered into a textbox, is not very helpful, and it doesn't seem like a
>> very useful test to me.
>
> How do you make sure that the data entered into a form is propagated to  
> your
> business domain?


If I test like a user I need to see if the data is propagated into the  
layers below as a user could. Entering some text into a field, should  
probably have some inpact in another screen and I could checkk there if  
that happened.
>
>> Now testing from the customer's perspective, you should test only from  
>> the
>> user interface, and have nothing to do with the controller. A test  
>> should
>> follow the steps of preparing, acting and verifying but all from one
>> perspective, and if that's the user perspective then , maybe entering a
>> username and a password in a login panel is the preparation and acting  
>> is
>> clicking the login button, and depending on the data introduced  
>> verifying
>> is testing whether you've reached the right screen or that you have a
>> message box saying that your credentials are wrong. I think that this  
>> can
>> be very well done using NUnitForms, although I  saw that usually using
>> NUnitForms means writing a lot of code (I even wrote something about it:
>> http://danbunea.blogspot.com/2005/08/simplifiing-nunitforms-functional.html).
>
> If for example the user wants to be able to commit your login dialog by
> clicking the Ok button or by pressing the Return key. How do you make  
> sure
> your dialog supports both?

I think NUnitForms already supports this trough KeysController  
(http://cvs.sourceforge.net/viewcvs.py/nunitforms/NUnitForms/source/NUnitForms/KeyboardController.cs?rev=1.8&view=auto)  
but I have never investigated. In my belief it is much simpler to verify  
the two scenario's by hand then writing a test. I have the tendency to  
write tests mostly for functionality and not for absolutely every case,  
because this might generate maintainability issues  
(www.testautomationpatterns.com). However, I think there might be cases  
when this is a feature requested by the client, that he values much and in  
this case it should proabably be automated.
>
> I think NUnitForms is a good tool for doing UI tests. The problem I have
> with it is, that the low level keyboard and mouse actions do not work in  
> all
> scenarios. Using .NET's SendKeys class solves some of those problems. I  
> will
> investigate if it makes sense to use SendKeys inside of NUnitForms.
>
>> And if you don't want to be testing exclusivly from a customer
>> perspective, I think Model View Presenter is a very good choice for TDD
>> (http://danbunea.blogspot.com/2005/11/model-view-presenter-is-testing_27.html)
>
> Agreed. But there is still the problem of testing that the controls on  
> the
> form behave as expected.
>
>
> Sincerely,
> Stefan Lieser
>
>
Thanks again,
Dan Bunea
http://danbunea.blogspot.com

>
> To unsubscribe, email:
> TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
> Yahoo! Groups Links
>
>
>
>
>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
    TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/