C# > September > DUH! Moments

• When working with I/O, Streams, Writers, etc. ALWAYS use 'using{}'
• In regex the '?' makes the preceding item optional:
• Or: '?' in regex means '0 or 1'
• An? (matches both A and An)
• 23(rd)? (matches both 23 and 23rd)
• In SpecFlow: when using regex step definition bindings you can create step definition methods with multiple parameters easily by having multiple (.*)s in the regex.
• C#/.NET syntax for pattern matching:
• string pattern = "[regex pattern]"
• string input = "[input]"
• Match match = Regex.Match(input, pattern);
• AssertTrue(match.Success) etc.
• Useful methods of DateTime objects:
• myDateTime.AddDays(int days)
• myDateTime.AddMonths(int months)
• etc.
• In Visual Studio: when debugging the immediate window is an amazing section where you can type statements which will be immediately executed and the value shown.
• A class containing [Fact]-s for xunit.net should be public
• ?? operator
• if/else operator with nullable argument
• LINQ:
• var query = from element in collection select element.attribute
• var query = collection.Select(element => element.attribute)
• In regex:
• '+' means '1 or more'
• '$' means 'end of string or end of line'
• '\d' means 'digit'
• Working with the JIRA REST API and the JIRA Zephyr API (ZAPI) I've been making my very first steps in web-based APIs. So there are a LOT of "DUH!" moments. The most newbie one so far:
• We have GET requests, and POST requests.
• GET requests:
• Have no body
• Arguments to the request are passed via the URL.
• Example: /api/latest/resource?argumentName=argumentValue
• POST requests:
• (Can) have a body
• Arguments to the requests are typically passed via a body (such as JSON)
• If you don't follow these rules you get fancy error messages such as:
• "Cannot send a content-body with this verb-type".
• The different calls and what they mean:
• GET: read
• POST: create
• PUT: update
• DELETE: delete
• (apparently there is PATCH as well - no idea what it is)

MTM > Microsoft Test Manager > First Steps

I will have to setup a test automation framework at my new job and considering the fact that my new company essentially uses the entire Microsoft stack I'm going to see if Microsoft Test Manager (MTM) will suit our purposes.

Long live the Pluralsight courses:

• Structure:
• Test Plan
• Test Suite
• Test Cases
• Test Plan Configuration
• What are you testing?
• How are you testing it?
• Test Plans are now TFS Work Items
• Inside the Test Plan:
• Plan
• Test
• Track
• Organize
• Plan section:
• Contents
• Results
• Properties
• Test Plan Properties (& Run Settings):
• Settings
• Environments
• Assigned Builds
• Test Configurations
• Run Settings:
• Test settings:
• General
• Roles
• Data and Diagnostics (there is a LOT here)
• Summary
• Test environment
• This leads to the 'lab section' of the MTM which is out of scope for the course. TODO: Lab section MTM.
• Builds:
• Information about against which build the tests are ran.
• Configurations:
• Operating System
• Browser etc.
• If multiple configurations are applied to the Test Plan then a single Test Case will be 'created twice' - one for each of the configurations.
• Customizations
• Test Plans are now considered TFS work items, this has all sorts of handy consequences. Such as:
• Work Item
• Fields & States
• History
• TODO: Lean about Work Items.
• For example: make changes to the Work Items states with the help of Windows Powertools.
• Track section:
• Here we can query for Work Items (and therefore also Test Cases etc.)
• MTM Web Interface: with the correct licenses there is a really handy Web Interface in the case you require MTM on machines that don't have MTM installed.
• Plan: Create Test Suites and Test Cases
• Test Suites
• Types:
• Static
• Requirements-based
• Query-based
• Out-of-the-box states:
• In Planning
• In Progress
• Completed
• 
  
• Aside:
• Test Cases are now available as TFS work items
• You can add Test Suites to the Test Plan
• Be they Static, Requirements-based, Query-based, etc.
• You can then add Requirements to the Test Suite
• Doing so will open a window in which to query for TFS requirements
• Test Cases
• Are TFS Work Items with all the accompanying benefits
• Consist of Steps
• Can be assigned to Testers
• Can have their own sets of configurations
• Test Points
• Test Cases x nr. of configurations
• Test results are tied to a Test Point
• LEARNING MOMENT
• In MTM:
• ADD stands for adding something existing
• NEW stands for creating something... new(!)
• END LEARNING MOMENT
• Creating Test Cases:
• Steps
• Summary
• Tested Backlog Items
• Links
• Attachments
• Associated Automation

Aannnnnnnd... it's gone.

If the goal is to fail hard and fail fast we're not doing too badly, because after investing roughly a day into MTM it has become clear that this is currently not an efficient tool for my new company. So we're dropping the course and this line of MTM investigation. Next step: Zephyr for Jira!

TFS > Connecting to TFSVC on your Visual Studio Team Services account

The future is in the cloud. So as we try to get a grip on TFSVC let's learn how to get a grip on it in the Microsoft cloud dedicated to this: Visual Studio Team Services.

What we want to achieve:

• Set up a Collection (or at least a Team Project) in VSTS
• Create a Team Project in this Collection
• Add an empty Solution to the Team Project
• Add existing code to the Solution
• Perform generic version control operations on the Team Project/Collection

Set up a Collection (or at least a Team Project) in VSTS:

For guides/instructions we use - amongst others - the page:

https://www.visualstudio.com/docs/overview

Firstly create a Visual Studio Team Services account as described in 

https://www.visualstudio.com/en-us/docs/setup-admin/team-services/sign-up-for-visual-studio-team-services

Then 

TFS Version Control > First Steps

At my new company TFVC is used for version control on the source code. For me to be able to function in the development team I need to get a grip on TFVC.

The hierarchy of TFVC (from big to small):

1. Collection
2. Team Project
3. Solution
4. Project

A realization:

• The Source Control Explorer 'explores' the Workspace.
• The Workspace is the LOCAL copy of the Team Project - within a Collection - stored in TFS Version Control
• The Workspace is generally identical to the files in the directory which was mapped to the Workspace BUT it is possible for there to be files in the file system which are not added to the workspace.
• Add those 'missing' files via Visual Studio (Source Control Explorer, rightclick->Add to Source Control, etc.)

Facepalm moment:

When creating a new project (File > New > Project) the popup has four fields to fill in:

1. Name
2. Location
3. Solution
4. Solution name

Solution has a dropdown menu with three menu items:

1. Create new solution
2. Add to solution
3. Create in new instance

START LEARNING MOMENT
When creating a new project WITHIN an existing solution then use the menu item 'Add to solution' as described above
END LEARNING MOMENT

New job, new priorities

So we changed jobs. Still Test Automation, but different colleagues (internal developers yay!) and different tooling. Out with the Tosca, in with the .NET technology.

So the new goal is: let's learn how to work with the Microsoft technology stack.

Very useful link:
https://www.visualstudio.com/en-us/docs/tfvc/overview

We start with creating a solution and then adding it to TFVC:
https://www.visualstudio.com/en-us/docs/tfvc/set-up-team-foundation-version-control-your-dev-machine

But then we run into the situation that apparently it's not possible to connect to MULTIPLE Team Foundation Servers from one Visual Studio client. This is rather annoying since I was planning to do some experimenting on my own in the VisualStudio cloud separate from work, but this is apparently not possible. My manager created a new 'Team Project'

Current technical roadblocks to resolve:
1. Connect to the work TFS via VPN.

Tosca > TDM > Setting up

When working with Tosca sooner or later the need to store testdata in a database will arise. In Tosca this is supported via the 'TDM' functionality.

Before you can start writing testdata to a TDM database you'll need to create a 'class' in the TestCaseDesign section and assign attributes to that class corresponding to your TDM needs

• DO NOT FORGET to tick the 'TDM' column tickbox for every attribute which needs to make it into your TDM database.

Find the relevant modules in the section:
Modules\Tricentis\Tbox\Tbox XEngines\TestDataManagement



First create an object with the 'TDM Create Object' module.
Then set attributes with the 'TDM Set Attribute' module.
Then save the object to the TDM database with the 'TDM Save' module.

To retrieve an entry from TDM use the 'TDM Find Single Object' module. After the call an object with the given name is stored in memory. To access the TDM values of this object use the 'TD' function in Tosca:
{TD[[ObjectName].[AttributeName]]}

Tosca > TDM TQL search within a search

In our repository we have a TDM structure where the different TDM objects are linked with reletions. If you want to find one property via its link with another property this is done via a TQL query:

->RETURN All:[TDMObject1]->[TDMObject2][Property=="[property_value]"]

or: in human readable:

-> RETURN All:Portfolio->Client[Username=="login01"]