r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Cheyenne] Discussions about the Cheyenne Web Server

Janko
16-May-2009
[4717]
( Is there a way to show in browser while developing <== Is there 
a way to show whole output + error output in browser while developing, 
like it worked before )
Maxim
16-May-2009
[4718]
cool.
Janko
16-May-2009
[4719x2]
I don't know what I did but now I see output in browser..
now that I can see output this is what's going on... I see that on-page-start 
is called, I do " do %bin/somelib.r   do %bin/somelib2.r ..." there 
, but libs don't seem to get included
Dockimbel
16-May-2009
[4721x4]
What Cheyenne version are you using?
For showing errors in the browser, just put the DEBUG keyword in 
the webapp config block.
I guess you're using 0.9.19. DO has been redefined in the RSP engine 
to bind, by default, loaded code to webapp context. If you want to 
load libs that have to be visible in the global context, you have 
to use DO/GLOBAL.
That's one of the big change in RSP in v0.9.19.
Janko
16-May-2009
[4725x2]
Hi Doc. I am "porting" to 0.9.19 , the main thing that was causing 
causing the confusion since I didn't yet fully get it  was that "do" 
inside one of  another file that was "do-ed" didn't seem to use path 
relative to the that file but to web-app and before that wirtualroot 
property wasn't correct, I added the folder below root path.. now 
it works, and debug makes the whole output visible so I made it work 
better also.
But I have one really really big request for future if it's not yet 
possible :) could you make another flag besides debug (like devel) 
that would not add the debug info bar to webpages but would just 
show the error output in case of it (yer olde way - without the debug) 
.. or is this somehow possible to set up already?
Dockimbel
16-May-2009
[4727]
I'm checking the code to see if there's a simple way to do that.
Janko
16-May-2009
[4728]
I will survive if I have to be in debug mode all the time :) I thought 
it will add some output to ajax responses too and make them unworkable 
but you seem to thought of this :)
Dockimbel
16-May-2009
[4729x2]
The debug menu is inserted is a </head> or <body> tags are found 
in the output. Most of Ajax responses are either JSON data or HTML 
snippets (not reloading the whole page, so without <body> tag), so 
they're not modified.
is = if
Janko
16-May-2009
[4731]
smart
Dockimbel
16-May-2009
[4732]
There's no way to have the debug mode without the debug menu currently, 
but it should be easy to add an option to define the debug level. 
I'm adding that to v0.9.20 todo list (scheduled for releasing before 
the end of this month).
Janko
16-May-2009
[4733]
ok, thanks a lot ... one day soon I will buy rebol so I can do little 
hacks and "recompile" myself , so I won't need to bug you for smaller 
stuff
Dockimbel
16-May-2009
[4734]
The only case where this method doesn't work is when you need to 
send back XML data with embedded HTML (RSS for example). So your 
request is justified.
Janko
16-May-2009
[4735x3]
just one detail idea for improvement .. when you intercept redirection 
in debug mode you can use javascript to set focus on the link to 
continue already so developer just presses space or enter and it 
continues. No need to leave keyboard for mouse or to press tab tab 
tab .. enter :)  
document.getElementById('java2s').focus()
It seems app works with new one now .. no big changes were needed
I can send you link and username password once I set it on the new 
VPS
Dockimbel
16-May-2009
[4738]
Thanks for the JS advice, I'll add that too. You should read all 
the ChangeLog entries for 0.9.19 to check for potential issues with 
your code (the new RSP webapp default sandboxing is the biggest compatibility 
breaker).
Janko
16-May-2009
[4739]
but sounds also the most awesome stability feature :) ... I looked 
at it, I will again .. this is a simple app at the end so I can test 
it quickly 


so I won't only criticise the new debug/log functionality ... for 
having it on server it's awesome that the trace log is made so I 
can just look at it and see it there were any errors for users, etc 
.. for that endo of the deal it's great
Dockimbel
16-May-2009
[4740]
IIRC, you've proposed me some test scripts for Cheyenne, I'm very 
interested in such scripts. I have my own test framework, but it 
covers only a few basic test cases. I use it mostly for stress testing 
by simulating high loads (hundred of simultaneous requests).
Janko
16-May-2009
[4741]
aha, mine is reverse, no stress testing but functionality... I made 
it for webapps but with it you could also do automated testing on 
a sample of scripts and see at any point if all the features work 
.. it is very much in devel still ... I used it for testing site-assistant 
but it's more manual at this point.. I will impove it as one of my 
clients needs it for their app. I hope it will be more edible or 
usable soon, I will show it to you then.
Dockimbel
16-May-2009
[4742x2]
I was planning to write a full unit tests suite while making the 
documentation for Cheyenne 1.0. I hope to be able to reach that milestone 
before the end of this year.
I'm also planning to work (probably this summer) on a high level 
web testing dialect allowing to implement more complex use cases 
simulating the work of a real user.
Janko
16-May-2009
[4744]
Yes, unit tests are very good for pure functionality (functions that 
don't affect the state) ... this is strictly for webapps, webapps 
is basically based on some state so unit test don't make sense except 
for the algoritmic part of webapp ... you can see sometning about 
this testing engine here .. http://itmmetelko.com/blog/2009/04/24/a-peek-into-wip-trail-testing-engine/
Dockimbel
16-May-2009
[4745x4]
That's very interesting and inspiring work. It's close to my own 
thoughts about a web app testing framework. You're very right, the 
main target should be the webapp API, not the UI. That's why I didn't 
invest in Selenium, I don't want to update scripts every time I change 
the UI without changing features.
I was thinking about making a low-level dialect allowing to simulate 
user actions in a web browser. Then use that dialect to build a higher 
level dialect (specific for each webapp) allowing to navigate inside 
a webapp, make complex actions and check the result, using a minimal 
set of keywords. I haven't wrote down, nor refined those ideas, but 
it should be able to give you (at the higher level) something like 
:  
[
	go site-assistant
	signup 
		login: "[user-:-test-:-com]"
		pass: "pass"
	check-page default-page
	add-new-website
		website: "rebol.com"
		registrar: "registrar"		
	check-result site-created "rebol.com"
	check-details website-form "rebol.com" "registrar"
	... 
]
In this example, test data is hardcoded, but the dialect should be 
able to read data from scenarii blocks allowing to loop test a sequence 
of features using several data sets.
I'd like to have a test dialect being it's own meta-dialect, so that 
you can build higher level dialect one on top of the other, to be 
able to test you webapp at *any* level (from basic HTTP request, 
to full simulation of a working day).
Janko
16-May-2009
[4749x3]
yes, dialect based solution would be very interesting ... I was thinking 
about dialects a little too (not concrete yet) ... currently my testing 
engine is made so that it uses a proxy and it records your what you 
do via browser and then it can repeat the same and comparte the output 
(it already figures out that it needs to set different cookie and 
some basic stuff to login for example , and I have idea to make it 
scriptable for other dynamic data but I haven't come that far yet 
) . It also doesn't do any smart comparisson of the outputs, but 
more of a report for human to view for now
yes, that wou bo awesome
maybe we could join the approaches so that both use common comparisson 
methods and reporting
Dockimbel
16-May-2009
[4752]
The recording proxy can be a very efficient approach for non-regression 
testing.
Robert
16-May-2009
[4753x2]
A bit OT but Lad and I started a test-dialect for RebGUI. You could 
send CLICK to GUI objects etc. and compare results and state, make 
screenshots of something was wrong etc.
but it's not totaly finished.
Dockimbel
16-May-2009
[4755x2]
Robert: Good to know. Can it be used to VID testing too?
to = for
Janko
16-May-2009
[4757]
Robert cool
Dockimbel
16-May-2009
[4758]
Janko: I was planning for some very simple console-based reporting 
like: 
testing signup...
testing check-page...
### test KO : <error description>


But I'll be glad to join forces when both our approaches would be 
really usable. I didn't wrote any specification so far, I'm still 
at the idea stage. My main concern is to reduce the cost of testing 
regression for our biggest web-based apps in production.
Robert
16-May-2009
[4759]
VID: It shouldn't be that hard to adapt it.
Janko
16-May-2009
[4760]
my report is json data rebol2json and then javascript displays it 
all ,... it's all single static html file with data and javascript 
(via my jsgoo library :) )
Robert
16-May-2009
[4761]
I think I will pic-up the project in a couple of weeks again and 
push a bit forward and than it get useable.
Janko
16-May-2009
[4762]
so if your test will generate some relatively compatible data and 
if it would make sense to be presented like this we can do it
Dockimbel
16-May-2009
[4763x2]
Yes, I think we could come up with a compatible reporting format.
Robert: I would be interested in using it if it works with VID and 
also support keyboard simulation (especially VID hotkeys).
Robert
16-May-2009
[4765]
Here is a snippet of a test script:

new_company: [
	dt: "Eingabe/Firmeninformationen"

	with company [
		; reset data form
		press-right a

		check note = ""

		name: 		"Test Suite Company 1"
		address:	"Teststra§e. 10"

		; should bring up an ALERT
		check-window [press a][press ok]

		; country:	"Deutschland"
		; press a

		; select sector
		check-window [press req-sector][
			sector-table: ["27"]
		]
	]
]
Janko
16-May-2009
[4766]
Robert what you describe even if for GUI app sounds somewhat similar 
too.. I also take screenshots for example , and I also need some 
methods to chech and compare the state of app , that is still totally 
missing (and many other things)