May 2008 - Posts
In Team System 2008 we don't have a recording mechanism for GUI so how can we test the GUI???
The answer is: We will use the Unit Tests mechanism to cover the GUI tests.
Method: For each button we would like to invoke we will create a unit test that will invoke the button's click event.
Here is a simple example:
Lets take a simple win form project here is the form and the code behind it:
Now what we will do is create a unit test that will invoke the "btnClickMe_Click" method.
There are a few ways to create a testing project and a unit test but that is for another post,
I like to focus here on the concept of using the unit tests for GUI tests.
So the way we will create the unit test in this example is by right clicking the method name and choosing "Create Unit Tests..." option like it is shown in the picture:
Click on the "OK" button to continue...
Live the default name and click "Create"
The result will be a new test project with a unit test
Open the "frmSysUnTestTest.cs" file and make the following changes in the code:
- Add the line: target.txtToTest.Text = "pass"; (This line will put in the "pass" word in the text field we have on the form)
- object sender = this; (Setting the sender object)
- EventArgs e = EventArgs.Empty; (Setting the event arguments)
- Assert.IsTrue(target.pass); (This is the test's condition, in this case its checks the boolean parameter for "true" to pass the test and for "false" to fail the test)
Now lets run the test, again there are a few ways to run tests
in this case I will use the "Test View" window.
(In order to see how to get to this window see my post:
"Connect your test cases to work items in Team System 2008 Test Module")
In the "Test View" we will run the test.
and the results are:
So we can see that in this case the test passed.
One last thing on this subject, in Team System 2009 codename "Rosario"
the GUI testing is working differently but that is for a future post...
Hi,
Today I met a very angry developer. This developer and his colleague are using some generator that creates a huge text file (XML based but with its own file suffix) and this file is saved in TFS source control.
One programmer checked out the file, modified and checked in.
The other programmer checked out (assuming he was working on latest version - well, guess again...), and then tried to check in. Then, check in operation failed because of confilcts. Merging was suggested, but It's almost impossible to handle the merging of this file.
This programmer was blaming Team system: "This problem could never happen in visual source safe..." - In visual source safe, checking out operation always fetched latest version, and multiple checkouts were always disabled.
What's the best solution for this issue? Well, setting team system behaviour to work like VSS is a very bad idea. Martin Woodward wrote a great post about team system check out behaviour: http://www.woodwardweb.com/vsts/000179.html
Another suggested solution : Education... We must remember to check "Latest" indication in
Source control explorer before checking out.
I prefer this solution that seems to fit: If we decide that files of a specific type will never be merged, we can set them to non mergable files: Right click on TFS server, "Team Foundation Server Settings" -> "Source Control File Types..."
Then, click Add (or edit)
We can set for each file type wether merging and multiple check out will be enabled or disabled.
Does this functionality answer this programmer needs? Unfortunately, No.
Once a file is known as non mergable, multiple check outs and merges are disabled,
but still - check out does not fetch latest version...
So if we check out non mergable file *without getting latest version*, we can work all day on an obsolete version, and check in operation WILL FAIL on conflicts, without an ability to merge.
My suggestion to Microsoft: Please add the ability for automatic get latest on checking out a non mergable file.
Example:
Today I like to talk about the big difference between QA (Quality Assurance) and testing.
I was recently encountered a few times in a mixture between the two and it is a known mistake to mix between them.
QA process is a complex process that starts early in the project life cycle, some companies support starting the QA process from the project initialization which I personally strongly support, QA team has a lot to contribute in all the life cycle of a product.
It is well known that most of the bugs start at the requirements of a product, a good QA person has the ability to remove a large amount of the bugs from the requirements and to increase the products quality.
QA process needs to cover many aspects of the product, its quality, usability, security, stability etc. most of the problems can be eliminated early in the products life cycle so the total cost of the project will be significantly reduced.
Now we have got to the "Testing" part of the QA team where the code quality will be tested, in case the QA team has started early in the products life cycle this faze will be shorter and less expensive.
So has we can see from this introduction the rolls of the QA team in a project is much more than just testing, and if it is not the case in your project start checking if you are using the full potential of this great resource...
Note: I have written here a shot introduction that may offend some of the QA people, this is a short introduction and does not state the full QA process and roll in a project life cycle.
In my last post "Connect your test cases to work items in Team System 2008 Test Module"
I have talked about how to connect between a test to other work items in team system 2008
we have seen that there is no real connection between a test and work items,
the connection is made thru the properties of the test and there is no way of creating any
report using this information (test coverage report for example).
But...
In "Rosario" it's an all different story, the concept was changed and a hierarchy of elements
has been created to support the QA process needs, on this post I like to examine this hierarchy and I will do that "bottom up".
The first element in our "Journey" is the test case.
The test case in the "Rosario" is a work item so it can be easily connected to other work items in the system (Requirements work items for example) and this information can be manipulated in the reports.
The test case has a list of steps (Actions) and expected results for each step.
Next element is the test suite (also known as test set).
The test suite is an element in the system that groups number of test cases together.
The order of the test cases in the test suite will later define the order of their execution when running the test suite.
Test case can be added to more than one test suite.
The last element I will talk about is the test plan.
The test plan is an element in the system that groups number of test suites together (Test plans contains other elements but I like to talk about the concept and not to get into details), when running the test plan each test suite will be executed by its order in the list, each test suite will execute all its test cases by their order in the list and finally each test case will execute all its test steps by their order in the list.
By using this hierarchy the QA team can control the testing process in a more efficient way and to get all the reports needed to control the QA process.
When you start running a test you probably would like to know what requirements this test covers.
On this post I will show using an example how to connect between a test case and a work item of
any type using the test's properties "Associated Work Items" field.
At first I will create a test project and a manual test that I will later connect to work items.
In this example I use a manual test type but you can use the same technique in order to connect
between other test types and work items.
In order to get to the properties window of the test I will open the "Test View" window by clicking
on the "Test" --> "Windows" --> "Test View" as shown in the screen shot:
You can get to the properties window of the test using the "Test List Editor" too but I leave
that for the readers to explore.
In the "Test View" window I can see all my tests (In this case there is only one test),
I right click the test I like to connect and I choose the "Properties" menu item
as seen in the screen shot:
In the "Properties" window I will click on the (...) button next to the "Associated Work Items" field.
Now I click on the "Add" button to add a new connection.
In the window that has just opened I choose a query to run in this example I run the
"All Work Items" query to get all the work items in my TFS project.
Now I select all the work items to connect to this test by checking the checkboxes
next to them when finished I click OK.
The result is a list of the chosen work items connected to the test, in order to
see the details of each of the work items choose the work item and click on details,
when finished click on the OK button.
Now you can see that the work items are listed in the "Associated Work Items" field in the
"Properties" window of the test.
Now each tester before running a test can see what this test is covering.
One last thing in the Team System 2009 code name "Rosario" the all section of
test cases has been improved significantly more about that in a future post...
I was asked by quite a few people about the proper location of the wicc file and the dll file of the custom control in different versions of Windows. The answer is quite simple.
If you add Custom controls for the first time you should remember, Application Data / ProgramData are hidden folders and that some of the folders are to be created by the user.
The Location in Windows XP is:
TFS 2005: C:\Documents and Settings\All Users\Application Data\Microsoft\Team Foundation\Work Item Tracking\Custom Controls
TFS 2008: C:\Documents and Settings\All Users\Application Data\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\9.0
The location in Windows 2003 is:
TFS 2005: C:\Documents and Settings\All Users\Application Data\Microsoft\Team Foundation\Work Item Tracking\Custom Controls
TFS 2008: C:\Documents and Settings\All Users\Application Data\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\9.0
The location in Windows Vista is:
TFS 2005: C:\ProgramData\Microsoft\Team Foundation\Work Item Tracking\Custom Controls
TFS 2008: C:\ProgramData\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\9.0