We need a tool to test a set of fairly complex Java applications. The applications are mostly independent client programs or applets communicating with a servlet or apache server at a remote site. Specs:
Runnable on Windows XP, Vista and 7
Parameterizable (Can specify in a script the sequence of buttons to click, text to type in JTextFields and browser address bar etc.)
Can quit or bail out or display a nasty message if the expected window or dialog box doesn't appear
Record the output on the Java Console of browser in a .txt file (IE is sufficient for now) when the application opens a browser window.
While running, I should be able to see it running with folded hands while it would run
for a few minutes
We were thinking of writing an AWTRobot based tool that reads a command file and does this - (don't know how to do #3 or #4 yet - will ask you folks some day how to detect a window on the desktop). Would you suggest an open source tool available to do this? We don't need anything fancy to capture video or screenshots. Thank you, - M.S.
For browser based automated testing you can use Selenuim or you can use WebDriver.
The selenium project is hosted here
If you don't need to test the way the pages are actually rendered by the browser, but instead need to work at the HTTP/HTTPS/etc request level then have a look at JMeter. It has parametrization, dataproviders, graphs, and a proxy component for recording http user sessions.
If you do need browser testing, then, as has already been mentioned, Selenium is probably the best freely available tool. For production I would recommend using Selenium Remote Control server which can be driven by scripts written in Java/Python/C#/Perl/PHP.
To see what tools people use in real production environments, and to do your own research on what is available I recommend www.sqaforums.com.
Have a look at Sikuli
The reason I suggest this is it sounds like you need to test both a Java applet and the content of a native browser (launched from Java, but not itself Java) -- so it's not "Java all the way".
I'm not sure what you mean by criteria 4, though. It is worth noting that as Sukuli works by image analysis, it won't be able to copy text to a text file.
This question is an invitation for sales pitch, don't you think. How about Mercury Quicktest professional ( I believe its HP Quick test now). I do not believe this will be cheap either ( and well its HP, it will probably only work in IE ;)).
Since you want an open source solution, I believe, the most popular option is selenium and yes its a pain to configure sometimes ( like for Flex for example). So you should try Watir.
There is a lot of good buzz around it and when I evaluated it, I loved what I see.Also it does not work for desktop applications, I suggest you try some other solution for that.
(The problem is open source GUI testing tools are not usually all inclusive. If you need one solution to handle all your gui testing needs, then you should check out the more commercial ones like QTP.
I have used IBM Rational Functional Tester. It has everything you need and it's quite easy to learn. The scripting language is either Java or VB.Net so you won't have to worry about learning a language for your tests.
I had some pretty good results with Squish from FrogLogic and didn't break the bank: http://www.froglogic.com/products/
Did you try Squsih - http://www.froglogic.com/products/index.php
Related
Without thinking, I created an entire program in Java and began designing a website to use this applet. All it does is create image in a certain way but there is a bit more code (classifications and default values/images) that I just felt was easiest to do with Java. Now I have a Java app and HTML CSS and JavaScript that I can't seem to do much with.
I have thought of 2 ideas (below) but I don't know what the general alternative is to applets nowadays.
I have a spare PC I may use and just alter my applet to run the back-end of a server-based site instead, but I am hesitant to use my own IP and bandwidth for something like this. Also, this app doesn't even need access to the internet so this just seems like way overkill.
I could just release the .jar, but I plan on expanding the available options. I also told people that this website was coming. I'd like to be able to just update the website.
I don't really plan on writing my program in another language. This took me time to make. If there is no way to work Java into my site, I may just abandon the project altogether.
I am mainly concerned with Chrome for this problem.
Edit: I would like to use GitHub as my host, just in case this helps at all.
You can run anything you want on the server, including java programs. So
you could run the image creation program in the server and present the
resulting image using a standard img tag.
So, I have a fully functioning html/javascript/css web app, not sure if that's the right term, it works fine and dandy in a web browser.
The thing is I now have to move it OUT of a browser, OFFLINE, and to the "desktop", make it a standalone app. I would have to somehow wrap it in java/c++/python something, to make it run like that.
I really like Java since that is the language I know out of that list. I have looked into Rhino & Gecko. I haven't really found anything that is a nice plug and play. Like here is my .html file now run with it. I assume it would have to be in a swing window or something too.
Any hints/help/comments?
(As per request, I reposted my comment as an answer.)
The Atom editor is built using only web technologies, and uses the Electron framework (based on the Chromium browser) to run as a standalone application, with no external browser dependencies.
It looks very easy to set up something similar yourself, and basically just requires you to put your files in a special directory. (Electron uses a lot of space, though, so it may not be practical for distributing applications below ~20 MB.)
If you are really looking for an option where you just point at your current html and are off then you might just want to configure run a local web-server. It changes almost nothing about how you are running your application except where it is being served from.
I am looking for an addition for our "livestream and podcast" solution, which uses a camera to film speeches in our house.
It has been requested to view the slides of our speakers directly as a image in the webbrowser instead of the video stream. We don't want/can not install software on the speakers laptop, so I thought about a Java applet, which the speaker can just run via a webbrowser.
So what I need is technically this:
[speakers laptop] -> [Screencapture every N seconds via applet on a webpage] -> [Displaying the screen of the speaker on a different webpage for the external viewers]
I know there are Java applications which do record the screen, but save the file output locally. I need something that does the same, but sends the image to the server. On the server side I thought about a websocket.js accepting and displaying the image (other suggestions are welcome).
It would be great if somebody could help me out here. Btw, I never programmed in Java, so telling me which frameworks I need won't really help me.
Thanks!!
I was recently asked to evaluate possibilities for live screen-cast via applet. Most video APIs do not support codecs that have high enough compression (e.g. JMF). Some APIs can do advanced formats (JFFMPEG, Xuggle) but also use natives. While natives are normally no problem for an app. launched (free floating) using Java Web Start or a Plug-In 2 applet, the makers of Xuggle identify 'the order of loading natives' as a problem (e.g. won't work) for both JWS and applets.
It is a pity that more than a decade into its development, Java has no reasonable API for video capture/processing that can be deployed for a wide use (applet/JWS based - for the 'general public') GUI.
Perhaps you can find a solution using Flash.
Update 1
In fact, I do not need the screen to be recorded as a video.
In fact, you mentioned much of that in your initial question, but I focused on just a few keywords before drafting a reply. My bad. :P
OK.
Getting an image is relatively easy. An applet would need to be trusted in order to get a screenshot, but once trusted, it is just a few lines of code to get the image.
Encoding the image to JPEG of particular quality/compression setting (in memory) is also doable.
Sending the image to the server would depend on the size in bytes and connection speed, but one image with a high compression, every 10 seconds, should be doable. The server would need to implement functionality to accept the image.
As far as displaying the image on the client, it seems you already have some ideas based around JS. If you can make that work that would be optimal, since it can then be viewed in browsers with no Java.
I would still recommend you deploy the app. to the 'speaker' using Java Web Start, rather than embed an applet. A JWS app. will give you less deployment & maintenance troubles, and the JWS launch is ..nicer. Further, a free floating frame launched using JWS can minimize itself (or in later JREs, become transparent), during the action of taking a screen image - thereby capturing everything on the screen except itself.
Update 2
I actually found this code here.
That is ..horrible. Not the code, the site. When I visited it I got a message saying a pop-up had been suppressed (fair enough). Then there was the irritating 'vibrating dialog' hovering in the middle of the page (and following the scroll). You click the little x to see - another tab opened with yet another floating dialog, saying some other rubbish about how "You've won.." - with sound loud enough to drown out my high volume trance/dance playlist.
Then after closing that the hell out of my FF, I go back to the original page, close the damn 'dialog', scroll down & see.. a red background to the code (shudder). That is as far as I could manage. I closed the page with the code.
Try this code instead, for a single screen-shot.
Would it be possible to use this on the client side..
Yes.
.. and receive it with javascript on the server side?
Not really. Unless you mean an IIS based server running Microsoft's JScript. JavaScript is a client side technology.
For security reasons, servers need to protect themselves. E.G. From:
Someone creating a slavebot that uploads all the 1000s of docs on the slave machine's to the site - to make it crash.
People high-jacking your server for storing and serving bestiality porn (or worse).
Because of things like that (bad people have lots of imagination), while servers can easily accept uploads, they are generally not configured by default to allow them.
.. (I don't want Java on my server ;-)
It can be done using PHP, ASP, CGI etc. It does not need Java specifically, but it does need some active involvement from the server, if only to check the size of what is being uploaded and abort if it gets too large!
..Will take a look at the link you posted, but as I said, I can't program in Java, though I can understand some of it. Thanks!
It sounds like you'll need some help getting the server-side of it ready, as well. It is trivial for someone that knows how (not me), but a potential security nightmare for the inexperienced.
Update 3
where do I add the function to send the picture?
Sorry. I've not tried to implement that - you'd want to want to encode it to JPEG before sending, to reduce the size. See this code for how to provide an adjustable compression/quality where the user can see the effect.
There are various ways to get an image to a server. E.G. sockets, HTTP, FTP.. AFAIU it would depend on how the server is accepting it. I am unfamiliar with the specific term 'websocket' or the node.js script. Can you link to what you mean?
..the old code added to pastebin, so it's readable
Smart thinking. I notice it uses sockets, it was in the back of my mind that sockets would be best for this, since they have low overhead and short wait times.
I need to display any web page as a browser field,not browser session.I am building the app in 4.7 OS.Can anyone help me with sample code?
On 4.7 you are stuck with the old browser field. Also known as Browser Field 1. It renders HTML pretty close to how it was on 4.5 devices. There is no way to take advantage of the newer browser that you invoke via browser session. So, you can forget about CSS2 or or JavaScript on the pages you want to render as a browser field. But for the fairly basic stuff it is good enough.
For the sample code - you really should check out and understand all the examples there are in the development package before starting writing the code. It will really save more time than take for learning. Look at components\samples\com\rim\samples\device\blackberry\browser\BrowserFieldDemo.java
I doubt that the problem lies with the browser field per se. Rather with communications.
The people in the post that you refer to were probably suggesting ";deviceside=true" as this gets around the "BES effect" in a simulator.
You may wish to experiment with running the MDS emulator alongside the simulator session as well. There are a number of posts that discuss the impact of deviceside and simulation. You can test in code to see if you are running a simulator so that you can programmatically influence the "BES effect".
I recently played around with the SWT browser widget (which is great). I am wondering if I could write a full desktop application with it (with java services behind - e.g. persistence) and what drawbacks I would have to consider. The advantage would be that people without java knowledge could work on the gui. Of course it depends on the requirements and I know that this is not a very specific question. But mabye someone already tried to build a bigger app this way and is willing to share insights.
Thanks
Marcel
I'm not sure I share your opinion of the SWT browser widget. AFAIK it's merely a shell into the default browser on your machine, merely with a few API access points. I've used it for minor things when I needed to show a web page from within the application. But writing a whole application? That doesn't make sense.
If you want to build a web-based application that runs in the browser against a Java based server framework, there are many AJAXian frameworks to do it. You'd still be doing JavaScript for your client code. And you'd still be dealing with all the complexities of different browsers. I'm not sure why you would want to host it inside an SWT application instead of just directly in the browser window.