Subscribe to SQM and join the other 100,000 monthly readers

Always have the most current updates on software, Agile, mobile development, testing and more right at your fingertips.

Subscribe by email:

Your email:

Search

Current Articles | RSS Feed RSS Feed

How to reset your password, no matter what

 
Login

The "Lost Password" Function

How being honest makes Smart Bear profitable even now

 

One thing no one can complain about is Barak Obama's (verbal) support of transparency in government. More accountability benefits everyone.

Hardware Requirements for Large Installations

 

We frequently get asked: "How big a server do I need for running Code Collaborator?"


The recommended hardware for 100 users is here:

http://smartbear.com/docs/collab-manual/server_technical.html

For a larger installation, we recommend 8GB of RAM and at least 4 CPUs.  The rest of the configuration above is fine.

But it's a really hard question because once you have, for example 1000 users, that means many different groups with very different usage patterns.  Some use Code Collaborator daily, others monthly, some are in the same time zone and some are not.

The reason that matters is that it's the peak concurrent workload that controls the hardware requirements. In other words, the number of users who are signed on and actually participating in reviews at the same time - that's when server activity peaks and server resources are scarcest.  And with large installations it's hard to match "number of users" with "peak usage numbers."

The values above should work, however, and we have customers running successfully with peaks of more than 300 concurrent users accessing the server at once.  Also note that you can always buy more servers and distribute the workload without having to stop using the original server.

2:22 a.m.: Honey, Get Up. There's a Skunk in the Stove.

 
SkunkCartoon3

A few words I never thought I'd utter: "Honey, get up. There's a skunk in the stove." This bizarre adventure started this morning at 2:22 a.m., when I woke reluctantly to odd scuffling and squeaking sounds. Half-asleep, I stumbled into the kitchen and turned on the lights to investigate, feeling a little like the kid in Close Encounters.

How Not to Do a User Interface

 
Submit

I have long admired Mark Hurst's This is Broken series of blog posts. I'm always on the look out for bad user interfaces and I encountered one the other day in an online survey. The topic of the survey is unimportant, but it was built with Zoomerang; please note that I'm guessing Zoomerang's competitors are also less than perfect (as is our software, for that matter).

AccuRev, Code Collaborator, and Eclipse

 
Arss

A key feature of Code Collaborator is that it allows you to work within your existing development context, where context specifically means: the version control system that you use. After all, to share changes that you have made with co-workers so that they can do a code review, the most natural way to define those changes is with the terms used by your version control system.

Enhance File Checkpoints with WinMerge

 
If you have to compare files when you're testing, you've probably come across TestComplete's File Compare checkpoint. This feature allows you to see if two files are identical at the binary level. However, you're probably also interested in seeing what specifically about those two files are different. To help with that, TestComplete allows you to integrate with a number of 3rd party diff tools. In this article, you'll learn how to integrate WinMerge with TestComplete.


WinMerge is a free open source file comparison utility, which can be downloaded from this location. http://winmerge.org/downloads/ Once you've downloaded and installed WinMerge, you're ready to connect it up to TestComplete. To do this, launch TestComplete and go to Tools>Options. In the Options dialog, expand the Engines node, and then select Stores. Under the Files Diff Utility heading:
  1. Check the Active box.
  2. In the Diff Name field, click the elipses button and browse to where you installed WinMerge. (Typically C:\Program Files\WinMerge\WinMergeU.exe)
  3. In the Command Line Options field, enter /e /x /s /u "%s" "%s" (Each option is explained below)
  4. Make sure the Wait Until Diff Closes box is unchecked.
  5. Click OK


Here's a brief description of what each of the command line options used in Step 3 do:


/e enables you to close WinMerge with a single Esc key press. This is useful when you use WinMerge as an external compare application: you can close WinMerge quickly, like a dialog. Without this parameter, you might have to press Esc multiple times to close all its windows.


/x closes WinMerge (after displaying an information dialog) when you start a comparison of identical files. The parameter has no effect after the comparison, for example if the files become identical as a result of merging or editing. This parameter is useful when you use WinMerge as an external compare application, or when you want to eliminate unnecessary steps by ignoring files that don't have any differences.


/s limits WinMerge windows to a single instance. For example, if WinMerge is already running, a new compare opens in the same instance. Without this parameter, multiple windows are allowed: depending on other settings, a new compare might open in the existing window or in a new window.


/u prevents WinMerge from adding either of the files being compared to the Most Recently Used (MRU) list.


"%s" represents the name & path of a files that will be used in the comparison.



Now, when a file checkpoint fails, TestComplete will automatically invoke WinMerge and perform a file comparison. Let's try it out. We'll create two files with slightly different content, and then create a file comparison checkpoint. To create the files that will be used in the comparison:

  1. Launch the sample Orders application that ships with TestComplete. This is typically located at C:\Program Files\Automated QA\TestComplete 6\Samples\Open Apps\OrdersDemo\C#\bin\Debug\Orders.exe.
  2. Click File>Open, and select C:\Program Files\Automated QA\TestComplete 6\Samples\Open Apps\OrdersDemo\MyTable.tbl.
  3. Click Report>Generate Customer List. A Save dialog appears. Save the file as custList1.txt and note its location for later.
  4. In the Orders application, right-click on the Charles Dodgeson entry and select Edit. In the dialog that appears, change the Customer Name to Lewis Carrol and click OK.
  5. Click Report>Generate Customer List. Save the file as custList2.txt and note its location for later.
  6. Close the Orders application. Do not save changes.


In TestComplete, click the Create File Checkpoint button. In the File 1 and File 2 fields, browse out to custList1.txt and custList2.txt, respectively. Accept the rest of the default values. Your code should look something like this:

When you right click inside this function and run it, TestComplete compares the two files, and then launches WinMerge, which highlights the differences between the files. The test log panel contains a line marked Files.Compare result. If you accidentally close WinMerge, you can click on the Files1.batx link in the Test Log's Link column, and TestComplete will redisplay WinMerge with the file differences highlighted.


So now you can quickly and easily see what's caused a file checkpoint to fail. Until next time, onward automation!

Autorun for JsUnit tests

 

While writing some Javascript unit tests using JsUnit today, I finally got sick of having to enter my test page's URL in the JsUnit test runner page. More friction means fewer tests. I went looking in the JsUnit documentation and found that they have some handy query strings, but did not seem to have a simple function for doing this. No problem, I hacked one together and it works great:

Integrating with Static Analysis Tools

 
DblA

A common question I hear is: "How can I integrate Code Collaborator with a static analysis tool?" The answer lies in the command line tool that is part of Code Collaborator: ccollab. It provides a wide array of features, including two that are key for this type of integration:

Come See Us at SD West 2009

 
SEEUSSDW


Smart Bear Software will be at SD West 2009 in Santa Clara, California. We'll be in booth 220 on the exhibit floor and will be happy to talk about code review in general or Code Collaborator in particular. We will be handing out free copies of our book: Best Kept Secrets of Peer Code Review. (Note: you can always request the book for free here).

Every 7 Seconds

 

The other day I received an email from one of our customers telling us how well Code Collaborator was working for his team and how "developers are chatting like school girls in there!"

Comparing Migrated Database Tables

 
Many people have to migrate databases during the course of their testing. Perhaps they're upgrading to a new version of SQL Server, or perhaps their table structure has changed. Either way, they want to make sure that the information that was in a table in the old database exists in the corresponding table in the new database. This article provides you with the information you need to perform this type of verification.


Here's my scenario. I have a database called BooksSamples, which has been migrated to a database called migratedSamples. I want to make sure that all the information that was in the Authors table of the original BookSamples made it over to the Authors table in the migratedSamples.


To do this, I'm going to get all the records from both the original Authors table and the migrated Authors table and store them off as xml files. Then I'm going to have TestComplete compare the two files via an XML checkpoint and log any discrepancies.


Let's start out by adding an empty XML checkpoint to our project. We'll use this checkpoint later to perform the actual comparison between the two record sets. To do this, expand the Stores node in the project explorer tree, right click on the XML node and select Add>New Item. In the Create Project Item window, enter a name for the checkpoint (in my case I took the default of XMLCheckpoint1) and click OK.


I've also created ODBC datasources for both my databases. I could use full connection strings, but I find that ODBC datasources are easier to read & reference. I named my data sources BooksSamples and migratedSamples, respectively. If you don't know how to create datasources, click here


Now for the code. I started out by writing this queryRunner function. It does the heavy lifting for this test, meaning it gathers all the records from a database table and saves those records off as xml. The code is fully commented, so you can see what each line is doing.

Custom views and Oracle: The tyranny of capitalization

 
Oracle Buildings

Oracle has a funny way of dealing with capital and lowercase letters in things like tables and views.p But then, Oracle is funny about a lot of things.

Why we don't allow deleting comments in Code Collaborator

 

One of the questions we get asked all the time is: Why don't you allow users to delete comments in Code Collaborator?

All Posts