Three types of testing:
#1 knowing what you're looking for and then go looking for it
#2 throwing the kitchen sink at something hoping whatever is wrong will pop up with a red flag painted across its chest
#3 you think you have found an issue but you don't know why it's an issue so you're not sure it's an issue...go to #2
Testing is a process. Testing requires extensive knowledge of inner workings of things. Testing takes a lot of time. Testing requires a strategy that is integrated with your development process.
With all that said, if you know what you're looking for and you have a clear idea of how you're code changes might screw something up -- then simple clicking through your solution by hand and watching a few log files does the trick. We have this philosophy when we test this way: put the evil spastic monkey hat on and do our best to break something.
Tools by themselves are not a magic bullet but they can help automate the evil spastic monkey. For GUI apps, we use:
- Selenium (
http://seleniumhq.org/)
For web performance:
- ping
- Speed Tracer (
https://developers.google.com/web-toolkit/speedtracer/)
- resources, profiles, and audits tabs of Chrome developer tools
Logs:
- Servoy performance and error logs
- Database query and caching logs
Knowing what to look for smart client:
- write up we did years ago:
viewtopic.php?f=22&t=12810&st=0&sk=t&sd=a&hilit=speed&start=15#p65469Knowing what to look for web client. We could probably write a book on this one too (we were the ones that found the glaring web speed issues with 6.1) but some tips for now:
- keep ping time to the server at 50ms or less. anything more starts to impact client performance
- hack servoy's blocking cursor (
http://www.servoymagazine.com/home/2012 ... ation.html). Huge impact on perceived client performance. 6.1.3 has a new hour-glass setting I think that does the same thing but not sure if it follows the mouse around like ours does
- paged grids vs scrolling grids: we like the user friendly-ness of scrolling grids but they are still a work in progress so can be a bit quirky. with 6.1.3 they are usable. if you don't want any quirkiness, use paged grids
- everything runs on the server with web client...single threaded by default! if you trigger a long running method, it will block the client UI. Use headless client plugin if you can in these situations (ex: compiling a report)
- use css3 instead of images for all gradients, rounded corners, etc
- put default styles in the servoy server root alla harjo's alternate css (
https://www.servoyforge.net/projects/servoy-default-css)
- use even, odd, selected classes for row background coloring instead of rowbgcalcs
- use onRender event instead of rowbgcalcs
- pro tip: form onShow remove all graphics using solution model (set image media to null), add in a style class that pulls image from a sprite residing on the server and part of the harjo css (or a swc wrapper in our case). Servoy sends each image down the wire individually and this technique completely takes all that noise out of the picture. Maybe I'll write this one up sometime.
- get friendly with WebClientUtils plugin. Do things client-side when it makes sense.
Expectations:
- Servoy web client technology is all about development flexibility. Extreme speed is not its strong suit. With that said, we're getting some decent results speed-wise with very complex GUI solutions.
- note that some of the smart client gotchas are the same for web client. If you show a grid with several columns of calculations that reference related data...you get the picture. Instead, grab all the data in one shot with a sql query and push the resulting dataset into a foundset and then into the grid.
Off the top of my head brain dump for now. We've been hard-core testing web client since Servoy 6.1RC's last Spring so if you need an extra pair of eyes...we can spot issues pretty fast now. Cheers.