Have been trying to work with some real Selenium projects using Java as the programming language. It is interesting to work on this and have been trying to come up to terms with a new language for use with Selenium. The main was the use of Eclipse as a IDE to build the test suite has been a great learning experience.
So the basic thing to do is to record the actions of the web application using the Selenium IDE, then convert the test case into Java/JUnit test case. Copy the code from the Selenium IDE window to the Eclipse IDE. Make some changes so that the code looks beautiful, and Eclipse gives some great pointers to correct your mistakes. And Voila! you have a test case written in Java and ready to be run with/as a JUnit component :-)
A generalized code is given below:
/**
* @author: gagneet
*
*/
package com.cookie.selenium; //this can be made on your own as a package into which you place all your code. Java requirement.
// some library functions that I am making use in my code.
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.FileReader;
import java.io.FileWriter;
import java.io.IOException;
// The Selenium packages from ThoughtWorks
import com.thoughtworks.selenium.*;
// The test case class. The name of the class has to be the same as the file name with .java
// You do need to extend the SeleneseTestCase base class.
public class ReadURL extends SeleneseTestCase {
/**
* To open the first instance of the browser and initialize the same.
*/
public void setUp() throws Exception {
setUp("http://www.yahoo.com/", "*chrome");
}
/**
* @param args
*/
public static void main(String args[]) {
Selenium selenium = new DefaultSelenium("localhost", 4444, "*chrome", "http://ad1318.rm.sp1.yahoo.com");
selenium.start();
selenium.setTimeout("30000000");
try {
BufferedReader inputfile = new BufferedReader(new FileReader("C:\\out.txt"));
BufferedWriter cookiefile = new BufferedWriter(new FileWriter("C:\\cookie.txt"));
String str;
// I am trying to read a file which has multiple lines, one line at a time.
while ((str = inputfile.readLine()) != null) {
selenium.createCookie("ABCdefGHI",""); // creating a cookie which will be sent along with the browser open
selenium.open( str );
selenium.waitForPageToLoad("120000");
String urlcookie = selenium.getCookie();
System.out.println( "URL :" + str );
System.out.println( "Cookie :" + urlcookie );
cookiefile.write( urlcookie );
cookiefile.newLine();
}
inputfile.close();
selenium.stop();
} catch (IOException e) {
}
}
}
In the above code, I am trying to read a file, which has multiple URL's. I read each line and then open the same in a browser window. Once it opens, I store the cookie value for that page into a file and also display it in the Eclipse log window (or the Standard Out - STDOUT).
Showing posts with label automation. Show all posts
Showing posts with label automation. Show all posts
Sunday, December 27, 2009
Saturday, April 8, 2006
Documentation
Back to the crux of all things - documentation. I suddenly realized why we need the documentation when suddenly a lot of people started to leave and the things that they had started here went for a toss as they have as yet not created any documentation in a Word Doc but only in their minds...
My PM came over today and the thing on his mind was to assimilate and get all the work that had been done by the people, into a single entry point on the version control system and then work on integrating the same for all the products and applications. Currently, the task I am doing is majorly centered on the Windows platform, but now I will have to check on all the products and all the platforms and see where all optimizations can be made so that re-work is not required. It takes a lot of effort and thought to create something but only a little bit of negligence to completely destroy the same. A prime example of the same is the test framework I am currently working on. Now we had a perfect version checker written in Perl, which used to check the version of the product installed by us and the version of the product as given by the executable. But the build and installer person decided that [or rather forgot] that he has to update the version number in the installed package. This made the situation that the version obtained from the package was different from the version given in the setup directory name and again different from what the user was entering it as. So came the problem that when we installed the product, the versions would not match and the product was again uninstalled, but as we were not checking the product version when installing, just the executable file was being checked, we used to install the product again, reboot and then get the version from the command line tool. This was matched with the version given by the user and again a loop as no match means uninstall the product... :-D
The main thing I next need to learn from this was never to trust anything where a human can make an error, as the famous words go, "if anything can go wrong it will" [along with "to err is human"] and the axiom added by my Project Manager from the first organization I worked in - "the thing that goes wrong will happen in front of the customer", which is this case was the QA team who were supposed to execute the automated framework. They took the build and the process went into a loop... :-(
So coming back to the documentation part now, I was as is by habit creating all these documents, but could not comprehend this eventuality of the loop as I have given above. So exactly what does the documentation do? Well! for the first part, it got us immediately to the solution of this problem. From the given documentation we already knew that something was going wrong in the comparable algorithm as every time we got the message that 'Version not Match' and then uninstallation of the product and after that again an installation of the same. On going through the comments [code documentation] for the installation, I realized that I had not catered for human error and thus the solution to the problem was to cater for this, a major thing which I realized for Automation of anything was FAULT TOLERANCE...!! This has to be built into the system, else all our automation efforts fail, if we are just spending time in monitoring the application which has been automated.
As for the documentation part of all the other tasks being done for the automation, I realised that none of the others had any sort of documentation to go with them, except the typical programmers prospective of code and go, the logic and document is within the brain of the programmer who created the wonder of an application in the first place and as I have said earlier an unmaintainable application which if not understood and needs change might be discarded later. Thus, I am now to get down and create a document or ask the people who created these applications in the first place to create the same... [ the second option definitely looks appealing... :-P ]
More coming' up...!!
My PM came over today and the thing on his mind was to assimilate and get all the work that had been done by the people, into a single entry point on the version control system and then work on integrating the same for all the products and applications. Currently, the task I am doing is majorly centered on the Windows platform, but now I will have to check on all the products and all the platforms and see where all optimizations can be made so that re-work is not required. It takes a lot of effort and thought to create something but only a little bit of negligence to completely destroy the same. A prime example of the same is the test framework I am currently working on. Now we had a perfect version checker written in Perl, which used to check the version of the product installed by us and the version of the product as given by the executable. But the build and installer person decided that [or rather forgot] that he has to update the version number in the installed package. This made the situation that the version obtained from the package was different from the version given in the setup directory name and again different from what the user was entering it as. So came the problem that when we installed the product, the versions would not match and the product was again uninstalled, but as we were not checking the product version when installing, just the executable file was being checked, we used to install the product again, reboot and then get the version from the command line tool. This was matched with the version given by the user and again a loop as no match means uninstall the product... :-D
The main thing I next need to learn from this was never to trust anything where a human can make an error, as the famous words go, "if anything can go wrong it will" [along with "to err is human"] and the axiom added by my Project Manager from the first organization I worked in - "the thing that goes wrong will happen in front of the customer", which is this case was the QA team who were supposed to execute the automated framework. They took the build and the process went into a loop... :-(
So coming back to the documentation part now, I was as is by habit creating all these documents, but could not comprehend this eventuality of the loop as I have given above. So exactly what does the documentation do? Well! for the first part, it got us immediately to the solution of this problem. From the given documentation we already knew that something was going wrong in the comparable algorithm as every time we got the message that 'Version not Match' and then uninstallation of the product and after that again an installation of the same. On going through the comments [code documentation] for the installation, I realized that I had not catered for human error and thus the solution to the problem was to cater for this, a major thing which I realized for Automation of anything was FAULT TOLERANCE...!! This has to be built into the system, else all our automation efforts fail, if we are just spending time in monitoring the application which has been automated.
As for the documentation part of all the other tasks being done for the automation, I realised that none of the others had any sort of documentation to go with them, except the typical programmers prospective of code and go, the logic and document is within the brain of the programmer who created the wonder of an application in the first place and as I have said earlier an unmaintainable application which if not understood and needs change might be discarded later. Thus, I am now to get down and create a document or ask the people who created these applications in the first place to create the same... [ the second option definitely looks appealing... :-P ]
More coming' up...!!
Monday, April 3, 2006
Batch Scripting
Did you know what all you could do with DOS Batch files??!! Did you think all you could do was start another batch file, call a few commands to run in sequence!! Well! With DOS and batch commands you can do a lot more, right - you can even read and write to a file, and also it has a somewhat restricted sense of sub-routines in it. So, finally I was introduced to the world of DOS Batch Programming. I learned that Batch processing is a lot more than I would have ever thought it to be. Can you image my surprise when I learned that you can do file manipulations using DOS??? And to add to that, even binary files can be manipulated using the simplest batch commands of DOS?!! Ever heard of the command FOR in DOS! Well! If you add the /F switch with the same, you get a wonderful file handling capabilities for DOS. Read up more on the posts by Mic, an avid and resourceful DOS Batch person, who I think would be able to answer all DOS Batch related questions you post to Batch World group on Yahoo!: Batch World
Well! I have had a fine time trying to work out what all I could to with DOS to help in my Automation work; as currently what I have created is a PXE server which can boot a machine into DOS, from here I have to carry on and cal the Acronis Command Line tool to accomplish my work, but all has to be done using DOS commands only as the environment into which the system is booted into is PURE MS-DOS with a few network enhancements. I now had to work out a way by which I can get my system to work by calling the Acronis Command Line tool and install an image for the system which will be Windows platform and configuration as selected by the user, as this is a dynamic thing, I have had to do a lot of work to create dynamic fiels which would do my work and heer I learned about DOS and Batch File commands. Currently, I have managed to get a working script which will help me in installing images stored by me on a server and a user configuration in which user selects his choice of OS file system to install and execute his test framework on:
@ECHO OFF
SETLOCAL
FOR /F %%y IN (c:\OSCount) DO CALL :READ %%y
SET /A countWr=%my_return% 1
ECHO %my_return%
> c:\OSCount echo %countWr%
ECHO %countWr%
GOTO :END
:READ
SET /A v_sum=%1
SET /A count=1
FOR /F %%x IN (c:\MyFileA.txt) DO CALL :ABC %%x
ENDLOCAL & SET /A my_return=%v_sum%
:ABC
SETLOCAL
IF %count%==%v_sum% ECHO This File %1
ENDLOCAL & SET /A count =1
:END
The above script is reading a file (MyFileA.txt) and getting the line number to be read from another (OSCount) file, which is then incremented for the next execution (the file is written to, we can also append to the file by using double greater than symbol - >>). Also, the variables are being passed as parameters from one sub-routine to another and then returned. So, finally, when we reach the first sub-routine again, the OSCount file is contains an incremented new value and when we run it again, we can get the next line in the file MyFileA.txt.
Although with the above script you can find out many things you can do with DOS batch commands - read a particular line in a file, write or append a line to a file, and even sub-routines in DOS!!! I never knew these were there. The SETLOCAL - ENDLOCAL actually defines a sub-routine in DOS. For debugging DOS batch files, you just do an @ECHO ON at the beginning of the file and execute the script through the DOS command line and viola, you can actually pin-point where you are going wrong - which line or variable is returning what value and where and when.
So, folks all I can say is that get your Windows machines pumped up and start using the powerful features of DOS which you might have never know existed... (PS: I have not added the code sent by Mic here as the link should take you to that, which is more nicely structured and concise!! My code is just a bunch of statements more meant to give an idea of what all DOS is capable of doing...)
Well! I have had a fine time trying to work out what all I could to with DOS to help in my Automation work; as currently what I have created is a PXE server which can boot a machine into DOS, from here I have to carry on and cal the Acronis Command Line tool to accomplish my work, but all has to be done using DOS commands only as the environment into which the system is booted into is PURE MS-DOS with a few network enhancements. I now had to work out a way by which I can get my system to work by calling the Acronis Command Line tool and install an image for the system which will be Windows platform and configuration as selected by the user, as this is a dynamic thing, I have had to do a lot of work to create dynamic fiels which would do my work and heer I learned about DOS and Batch File commands. Currently, I have managed to get a working script which will help me in installing images stored by me on a server and a user configuration in which user selects his choice of OS file system to install and execute his test framework on:
@ECHO OFF
SETLOCAL
FOR /F %%y IN (c:\OSCount) DO CALL :READ %%y
SET /A countWr=%my_return% 1
ECHO %my_return%
> c:\OSCount echo %countWr%
ECHO %countWr%
GOTO :END
:READ
SET /A v_sum=%1
SET /A count=1
FOR /F %%x IN (c:\MyFileA.txt) DO CALL :ABC %%x
ENDLOCAL & SET /A my_return=%v_sum%
:ABC
SETLOCAL
IF %count%==%v_sum% ECHO This File %1
ENDLOCAL & SET /A count =1
:END
The above script is reading a file (MyFileA.txt) and getting the line number to be read from another (OSCount) file, which is then incremented for the next execution (the file is written to, we can also append to the file by using double greater than symbol - >>). Also, the variables are being passed as parameters from one sub-routine to another and then returned. So, finally, when we reach the first sub-routine again, the OSCount file is contains an incremented new value and when we run it again, we can get the next line in the file MyFileA.txt.
Although with the above script you can find out many things you can do with DOS batch commands - read a particular line in a file, write or append a line to a file, and even sub-routines in DOS!!! I never knew these were there. The SETLOCAL - ENDLOCAL actually defines a sub-routine in DOS. For debugging DOS batch files, you just do an @ECHO ON at the beginning of the file and execute the script through the DOS command line and viola, you can actually pin-point where you are going wrong - which line or variable is returning what value and where and when.
So, folks all I can say is that get your Windows machines pumped up and start using the powerful features of DOS which you might have never know existed... (PS: I have not added the code sent by Mic here as the link should take you to that, which is more nicely structured and concise!! My code is just a bunch of statements more meant to give an idea of what all DOS is capable of doing...)
Saturday, April 1, 2006
Automation - Where, When and How?!

So counting all the OS and their respective platforms I came up with the 'magic number' of 51 and then suddenly realized that it was more (about 74) in all, on which we ultimately would have to execute our test framework. Coming to the framework part, this is another interesting story; and typical of the was a software development project works: First comes a super geek, who just sees the problem, codes and leaves with the basic framework setup completed, at the time the application was conjured. Then comes another who has to upgrade it to the latest version of the framework and the product. This person along with a few other underlinings, checks the same and does a modification of the existing framework. Now along comes me... :-) [I know self praise can be harmful, but everybody must take it sometime or the other, as in small doses, it really helps... :-D ]
With the complete documentation training that I have had till date and specially in my first job, I start with just documenting the code, and suddenly find that there is a lot more than documentation which is pending in the code. So, I get down to revamping the same so that it is workable with my new logic [this might have been the thing that the second person who got the code might have done, but not documented as properly] which is rather a lot of comments than code and the comments soon start becoming clear and the code starts to disappear... :-)
Coming back to the issue on hand - that of automating a system which has already been created by someone whose logic and understanding of the problem might be a bit different from what I have been doing, I came to the final conclusion that until I try and do a complete revamp of the existing code and either update or remake the code from scratch, I will not be successful. So, I start with the basics, which is all test cases should run. Now, the code for executing these test cases should run and finally the code should be in a structured manner.
The lesson I think I learn from the many failures of the system when you are trying to get something working is this thing to add FAULT TOLERANCE. In automation, this is one thing which I think I need to learn, should be built-in so that at any point the tests fail, the framework created should auto-recover and start with the next test case. This will be the final step before I finally automate the said framework for all images...
Next will be the actual automation process I employed for setting/installing and executing the test framework on multiple images and multiple systems at the same time. Which hopefully I should be able to do earlier than later...
Subscribe to:
Posts (Atom)