Selenium (not the Element)

Today's topic is selenium.   Selenium is this pretty nifty tool that helps for GUI "unit testing".  What it does is records all of your actions and then will play it back for you.  It's perfect when you make changes to the UI under the hood and want to make sure stuff works right.  So basically, it is a unit test of your UI.

I've already confirmed that it does work with the group projects (at least with my group's project).  So you can totally use it to help automate filling in forms over and over by a simple click of the mouse.

Selenium is basically another class to use in python.  (It also runs with Java, PHP, Perl, Ruby, JavaScript and many more natively).  So you can just make a new instance of a window and tell it to start clicking on things and filling in forms.  

But there is the best way, go get the Selenium IDE from seleniumhq.org/download.  The IDE is  firefox plugin.  Go ahead and install it.  Then go under tools and select it.  There will be a path name on the front, paste the google app engine link into it.   Click the red button off to the right and start filling in forms and navigating through pages and clicking on stuff.  When you are done, hit that red button again and then hit the play button.   It will start to play back exactly (or nearly exactly, Selenium is sometimes wonky when recording things but you can easily insert some commands to fix it) what you did.  Play with it for a while and see what happens.  You might like it or you might hate it.  Either way, I don't really care.

Any way there is a convert script to python tab menu thing and it will do that and generate a python script where you can add system calls and other functions you write (such as creating a table) and then run it as the Selenium script starts running.  Next time, I will go more in depth about this to give you time to play with Selenium because the next part is a pain to get to work and requires you to know how to do Selenium well.

Better version of what I've said.

Since we're working in teams now with many people.  It is a good idea to start using branches.  The reason behind this is if you check out the trunk, some one else does as well, and then your 2 other team members and you all start commiting changes.  Horrible horrible collisions will occur.  So if someone modifies something and then commits it and you are using an older version and make your changes to something else, everything goes to hell and it becomes a nightmare.  With branches, you will always get a good working copy of the code.  And once you are finally done, then your changes can be merged with the trunk so the trunk stays at a constant working condition with no horrifying problems.  Trust me, this is much better than it sounds, it creates less headaches and easier to manage.  It is also a good way to fix bugs without messing everyone else up.  So here's the method to use:

Branch the trunk to start your work
Remember, this is not actually copying all the files in the repository, its mostly a database change, very little space consumed. This operation should be considered consuming almost no disk space, and you should feel free to make branches anytime. The alternative would be messed up merges, miscellaneously copied files and lost SVN commits which is unacceptable.
# svn copy -m "[Issue number] Branching to develop a fix for Issue number." http:/google/trunk http://google/branches/Issue number

Checkout your new branch
# svn co http://google/branches/Issue Number

Fix your bug
# cd Issue Number/
# svn status
# vi ..
# make
# cd source/
# svn status -q

Commit your changes to your branch
# svn commit -m "[Issue Number] Committing changes for review to my branch"
Adds/remove files and junk.
Transmitting file data ...........


Review
Damnit man, someone should check your code by easily checking out your branch.

Merging your branch back to the trunk
Change into your branch directory
# cd Issue Number/

Switch your branch to point to the trunk
# svn switch http://google/trunk
The only thing here should ONLY ONLY ONLY BE IS FILES BEING UPDATED. NOT ADDED.
Updated to revision 29242.

Find the r number from when the branch was created
# svn log --stop-on-copy http://google/branches/Issue Number
------------------------------------------------------------------------
r29130 | not this crap but bellow.

[TL-1788] Committing changes for review to my branch
------------------------------------------------------------------------
r29129 | stuff here.

[Issue Number] Branching to develop a fix for Issue number
------------------------------------------------------------------------

Find the r number of the trunk
# svn info
Path: .
URL: http://google/trunk
Repository Root: http://google/storage
Repository UUID: 0e262ef1-e203-0410-bf88-cba8cc7d4a2f
Revision: 29242
Node Kind: directory
Schedule: normal


Merge the branch to the trunk
# svn merge -r29129:29242 http://google/branches/Issue Number

Look at your changes, now merged into the trunk
# svn status -q
# cd source

Commit those changes, if no conflicts, to the trunk
# svn commit -m "[Issue Number] Checking in fix for blah... to trunk"
...
Transmitting file data ...........
Committed revision 28953.



Remove your old branch
# svn delete -m "[Issue Number] Removing development branch" http://google/branches/Issue Number

Something about SVN, Jira and Trac

So at work we use all of that.

We use Jira to create bugs that should be fixed, Svn to get all the code and roll it all together and Trac to see who did what and messed everything up and view all previous versions.

Typically some one finds a bug or thinks of a good idea to add.  They will go into Jira and create a new issue with a great description of what happens that will get assigned to someone to fix it.  Jira will create a new page for this issue and give it a bug number.  The bug number [TL-XXXX] where X's are a number is then used to create a branch from the trunk where all work to implement this change will take place.  In Jira you can make comments on what was changed and specifically why.

Trac merges all of this together in a great way.  When ever you commit changes to a branch and give it a message, that message will show up on the bug page in "SVN commits" to let everyone know what you did and list all modified/added/deleted files.  Jira does this automatically. 

When you are ready for it to be integrated into the trunk on the bug page you have to change its status to "Fixed" and wait for some one to verify it to be correct.  Then you can commit this branch to the trunk and fix any conflicts.  And then you can change its status to "Integrated" and the bug is then taken off of the list of work in progess list.  Then delete your branch and Jira will track that message you give it.

Trac keeps track of all the changes and you can run diffs on multiple versions and see any conflicts or what was changed.  You can also view the files online as well.  Trac is a pretty good GUI system.

While Subversion is nice by itself, integrating it with Trac and Jira is great.  It makes it more complete.  It is a great combination for large scale projects that makes dealing with things much easier.

No one reads this thing.

Here is some nice Subversion info.

To better explain things, let us assume Downing has given us a project to do in which it has the first 4 projects in it somehow linked together.  The next steps are rough and you should figure out the commands properly.

Suppose there is a bug with Primes.py.  The proper way to fix this issue is to create a new tag in svn.  This allows multiple branches so while you are working on the problem, another person can come in and branch off and do something like implementing a nice GUI.  To do this do:

svn copy -m "Describing what you are doing"  

Where is of the form .../svn/project/branches/this new branch.

Then check out the branch and start working on it.  You should commit to this.  If you make changes to this branch, the trunk does not change until you merge it at the end.

So make your changes and a final commit.

Do: svn --stop-on-copy "your copy" to get the revision number (preceded by r)

do svn switch

Do: svn status -q and get the revision number of the trunk.

Do a svn switch branchR:trunkR       and this will point you to the trunk.

Do a merge.

Then now commit.

Congratulations your changes are now reflected in the trunk.

Now here is something you don't want to do.

In your branch do a svn add .  Then switch and do svn add to the trunk.  When you try to commit at this stage you will get an error saying that some file X is already in the trunk.

I got this error at work and took my a while to fix.  Since you are at the trunk any svn delete command will mess things up and actually delete files.  If you mess it up you can always revert it.

Do a svn delete  

Then do a commit again.  If get the same error with a different file  go back a line.  Else go to the next line.

Copy the files that were giving you trouble on your local machine (preferably good ones that work right before you messed things up) to a spot not in a branch on your local machine.

Delete the branch from svn.  Make a new branch and checkout the newest code (your missing stuff).  

Paste in the missing files/files that were giving errors.  Do a svn add to those files.  then commit and merge it back together. (Hopefully after making sure everything works again properly)

This should get rid of that error.  If you ever get this error, you now know what to do.

Making branches makes it very easy to add features or fix "defects" with out possibly messing up the code that everyone checksout.  Think about it, do you really want to checkout code that works horribly more or is incomplete and breaks alot of things.  Or would you rather get a good working copy and modify it.

Next post: SVN, JIRA, TRAC all rolled together.