Home > Archive > ASP > April 2007 > HELP: ASP & Javascript testing procedures & methods
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
HELP: ASP & Javascript testing procedures & methods
|
|
| Andrew Wan 2007-04-17, 7:56 am |
| I have been developing web applications with ASP & Javascript for a long
time. I have been using Visual Studio 2003.NET. While VS2003 is okay for
intellisense of ASP & Javascript, it's still not that great.
One of the cons of ASP & Javascript is that they're both interpreted, which
means one has twice the amount of work to do interms of syntax checking &
semantic/runtime checking.
Another bad thing is that ASP & Javascript doesn't have real object-oriented
features, like public/private members of classes. All functions are public
and accessible which causes bugs.
Does anyone know good testing procedures & methods of ASP & Javascript?
I have thought about 2 procedures where testing is split into Javascript
Client-side testing, & ASP Server-side testing. ASP testing can be done
using AJAX to see if "Page cannot be displayed" or the correct results are
returned. Javascript testing can be done to see if GUI-related things are
displayed properly.
This is still a lot of work, and the test scripts will fail if the main
webpage code changes. There must be better testing procedures & methods for
ASP & Javascript that is widely known & used.
| |
| Evertjan. 2007-04-17, 7:56 am |
| Andrew Wan wrote on 17 apr 2007 in
microsoft.public.inetserver.asp.general:
> I have been developing web applications with ASP & Javascript for a
> long time. I have been using Visual Studio 2003.NET. While VS2003 is
> okay for intellisense of ASP & Javascript, it's still not that great.
>
> One of the cons of ASP & Javascript is that they're both interpreted,
No, ASP is not a language but a platform.
What language under ASP are you using?
> which means one has twice the amount of work to do interms of syntax
> checking & semantic/runtime checking.
No, that has nothing to do with interpreting/compiling.
A compilesd programme can give you the same amount of headaches.
In fact sort of compiling is done at or just before runtime by most
modern script engines.
> Another bad thing is that ASP & Javascript doesn't have real
> object-oriented features, like public/private members of classes. All
> functions are public and accessible which causes bugs.
You could think it is bad, I think it is just right for the purposes
intended.
> Does anyone know good testing procedures & methods of ASP &
> Javascript?
Yes, modular scripting, setting stopping and logging breakpoints,
doing some logging on the realtime use and errors,
listening to the end users, and inviting them to report errors,
and especcially using your brain.
> I have thought about 2 procedures where testing is split into
> Javascript Client-side testing, & ASP Server-side testing. ASP testing
> can be done using AJAX to see if "Page cannot be displayed" or the
> correct results are returned. Javascript testing can be done to see if
> GUI-related things are displayed properly.
I doubt that. On all the different browsers and versions?
How would you do AJAX on a page that is not(!!) run?
Just testing if an .asp pseudo-img is downloaded by clientide javascript
will do.
> This is still a lot of work, and the test scripts will fail if the
> main webpage code changes. There must be better testing procedures &
> methods for ASP & Javascript that is widely known & used.
You want to take away all the joy that complex debugging gives?
Thankfully impossible, methinks.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
| |
| Andrew Wan 2007-04-17, 7:56 am |
| >>
>
> No, ASP is not a language but a platform.
>
> What language under ASP are you using?
>
Sorry, when I said ASP I meant VBScript.
>
> No, that has nothing to do with interpreting/compiling.
>
> A compilesd programme can give you the same amount of headaches.
>
> In fact sort of compiling is done at or just before runtime by most
> modern script engines.
>
Yes, I know IIS does some compiling/running but only when it runs.
>
> You could think it is bad, I think it is just right for the purposes
> intended.
>
VBScript is good for small scripts. However it gets messy when 10 developers
have contributed to hundreds of ASP/Javascript pages for one webapp.
>
> Yes, modular scripting, setting stopping and logging breakpoints,
> doing some logging on the realtime use and errors,
> listening to the end users, and inviting them to report errors,
> and especcially using your brain.
>
Yes, that is by manually going through clicking on the javascript submit
buttons to form post to a asp page, etc. It is still all manual. What I was
looking for is automated testing, like JUnit and use of assert()
functions... which VBScript doesn't have. That's why am looking for better
ways that are similar or automated VBScript/Javascript testing.
>
> I doubt that. On all the different browsers and versions?
>
For each piece of functionality, write a testcase for expected output.
Ofcourse we cannot test graphically but only search for certain strings on
the response text (eg. page loaded, etc). If someone didn't test their ASP
page then usually a syntax error will result in a "Page cannot be displayed"
page. It would be good for this to be automated to search for such pages.
Same for javascript,..
> How would you do AJAX on a page that is not(!!) run?
> Just testing if an .asp pseudo-img is downloaded by clientide javascript
> will do.
>
Yep, AJAX an asp page, parse the responseXML or responseText to see expected
output (ignoring layout/graphical issues). That will test VBScript syntax &
server-side logic.
>
> You want to take away all the joy that complex debugging gives?
>
Debugging & testing is ok and managable for a certain sized webapp. But when
it gets very big, then it's very time consuming, especially repetitive after
every test release..
| |
| Anthony Jones 2007-04-17, 7:56 am |
|
"Andrew Wan" <andrew_wan1980@hotmail.com> wrote in message
news:OuqkSYNgHHA.4156@TK2MSFTNGP02.phx.gbl...
>
>
> VBScript is good for small scripts. However it gets messy when 10
developers
> have contributed to hundreds of ASP/Javascript pages for one webapp.
>
I don't agree. You can still modularize VBScript in the same way you would
in any other language. Hence the problems of change control are the same
for VBScript as they are for VB6, C++ or any other language. You are using
Source control?
>
> Yes, that is by manually going through clicking on the javascript submit
> buttons to form post to a asp page, etc. It is still all manual. What I
was
> looking for is automated testing, like JUnit and use of assert()
> functions... which VBScript doesn't have. That's why am looking for better
> ways that are similar or automated VBScript/Javascript testing.
>
>
>
> For each piece of functionality, write a testcase for expected output.
> Ofcourse we cannot test graphically but only search for certain strings on
> the response text (eg. page loaded, etc). If someone didn't test their ASP
> page then usually a syntax error will result in a "Page cannot be
displayed"
> page. It would be good for this to be automated to search for such pages.
> Same for javascript,..
>
If you want this level of testing you need to develop your app around the
testing. For example you can seperate the output of data from it's
presentation by having processing pages generate XML instead of HTML. Tests
can post to and receive from these pages XML which should be invariant. XSL
or other tools can be used to transform the XML to a presentation. If that
presentation needs to change the processing tests remain unaffected.
| |
| Evertjan. 2007-04-17, 7:56 am |
| Andrew Wan wrote on 17 apr 2007 in
microsoft.public.inetserver.asp.general:
>
> Sorry, when I said ASP I meant VBScript.
I thought so. [not the sorry, but the vbs ;-) ]
Serverside jscript is a good alternative though,
more compact, object oriented, much more imaginative.
Why focus on vbscript?
[....]
> VBScript is good for small scripts. However it gets messy when 10
> developers have contributed to hundreds of ASP/Javascript pages for
> one webapp.
There is no need to use vbscript at all.
Jscrip will do fine.
It will only get messy if you do not programme modular,
so making black box functions that are thoroughly documented, tested, and
which bowel workings are not of interest anymore to the outside
programmer.
Yes, I know that needs a firm hrip by the head programmer, but that is
not different in a compiling environment.
>
> Yes, that is by manually going through clicking on the javascript
> submit buttons to form post to a asp page, etc. It is still all
> manual. What I was looking for is automated testing, like JUnit and
> use of assert() functions... which VBScript doesn't have. That's why
> am looking for better ways that are similar or automated
> VBScript/Javascript testing.
You can build that in using testing modules that you build yourself.
[color=darkred]
> Debugging & testing is ok and managable for a certain sized webapp.
> But when it gets very big, then it's very time consuming, especially
> repetitive after every test release..
No it is not, I mean it should not be, when you see building the test
environment as a logical part of the final site building.
And in the end, the testing should be done by user, as the developer
knows too much about the intention of the project to make those logical
sound "mistakes" the user makes. That is why the debugging code should be
part of the end product and enable logging and error reporting on
production run.
This is valid for all software development:
testing, testing, updating, testing ..., ad libitum et ad nauseam.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
| |
|
|
|
|
|