This question is locked. New answers and comments are not allowed.
sitefinitysteve
Top achievements
Rank 2
Iron
Veteran
Rank 2
Iron
Veteran
sitefinitysteve
asked on 23 Jan 2010, 07:40 PM
- Do you make your page, then create a new test for that page?
- Do you write Asserts and other things into your aspx.cs code?
- Do you write one large test to cover an entire scenario?
Just curious, because I'm just winging it right now :)
2 Answers, 1 is accepted
0
Hi Steve,
Thank you for opening this thread, the questions are quite interesting!
From my personal experience I've seen people doing all these. However, let me answer how would I approach that and the customers can share their preferable choice as well.
Do you make your page, then create a new test for that page?
Should I have a completed demo that cries for automation (example: any of ASP.NET AJAX or Silverlight RadControls live demos) I'm recording my tests against that. Of course most of those are simplified just to demonstrate a certain component functionality but even in case of a too complex page I don't see a reason to replicate the same page (e.g. copy/paste the source or part of it) into a test page in order to test that. If you go this way, once there is a change in the original page, you will probably need to update the test one as well.
Do you write Asserts and other things into your aspx.cs code?
I personally don't write the UI automated tests by hand unless there's some custom logic that needs to be performed in this particular test. That is too rare scenario though. Also, the recorder along with the translators are a really powerful way to generate your tests (I hope you agree on the easiness of recording against the typing by hand). Still, I've seen people using the recorder and translators to create their tests then converting their .aii tests to C# or VB code and run/maintain their tests this way. I personally wouldn't do that, I know how the code should look like anyway. ;)
Do you write one large test to cover an entire scenario?
Absolutely not, I don't record/write large tests and instead split that into separate smaller tests. Each test needs to follow one logical and complete scenario and IMO being as short as possible at the same time. Against the actions changing the application state you should have corresponding verifications, that makes the complete test.
I usually record about 10 sometimes up to 15 steps. If the test is going to have over 20 steps for example, I do my best to split it into 2 smaller tests. Just imagine the test some day failing at the very end and how much more time would you spend to analyze the failure just because of the too large test. Thus my advice in test automation in general would be to always think about the test maintainability, otherwise you risk to invest too much in an automation task that may not give enough in return!
I hope my post helps.
Sincerely yours,
Konstantin Petkov
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
Thank you for opening this thread, the questions are quite interesting!
From my personal experience I've seen people doing all these. However, let me answer how would I approach that and the customers can share their preferable choice as well.
Do you make your page, then create a new test for that page?
Should I have a completed demo that cries for automation (example: any of ASP.NET AJAX or Silverlight RadControls live demos) I'm recording my tests against that. Of course most of those are simplified just to demonstrate a certain component functionality but even in case of a too complex page I don't see a reason to replicate the same page (e.g. copy/paste the source or part of it) into a test page in order to test that. If you go this way, once there is a change in the original page, you will probably need to update the test one as well.
Do you write Asserts and other things into your aspx.cs code?
I personally don't write the UI automated tests by hand unless there's some custom logic that needs to be performed in this particular test. That is too rare scenario though. Also, the recorder along with the translators are a really powerful way to generate your tests (I hope you agree on the easiness of recording against the typing by hand). Still, I've seen people using the recorder and translators to create their tests then converting their .aii tests to C# or VB code and run/maintain their tests this way. I personally wouldn't do that, I know how the code should look like anyway. ;)
Do you write one large test to cover an entire scenario?
Absolutely not, I don't record/write large tests and instead split that into separate smaller tests. Each test needs to follow one logical and complete scenario and IMO being as short as possible at the same time. Against the actions changing the application state you should have corresponding verifications, that makes the complete test.
I usually record about 10 sometimes up to 15 steps. If the test is going to have over 20 steps for example, I do my best to split it into 2 smaller tests. Just imagine the test some day failing at the very end and how much more time would you spend to analyze the failure just because of the too large test. Thus my advice in test automation in general would be to always think about the test maintainability, otherwise you risk to invest too much in an automation task that may not give enough in return!
I hope my post helps.
Sincerely yours,
Konstantin Petkov
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
0
sitefinitysteve
Top achievements
Rank 2
Iron
Veteran
Rank 2
Iron
Veteran
answered on 25 Jan 2010, 12:59 PM
That does help, thanks!