Powershell in action, parsing XML

Back from the Christmas break, after a very busy period, let’s catch up on Powershell and XML.

Right before the break I was presented with a problem of parsing some XML files. The files all look like this:

<CONTAINER Name="X" Value="Y" Key="Z" ...>
    <NOTE Label="FirstCategory">02941ca7-43f7-4724-98c6-838f46bb2df9</NOTE>
    <NOTE Label="SecondCategory">b44561be-2176-48f7-9aa2-2ec70949cd7f</NOTE>
    <NOTE Label="ThirdCategory">48958fa1-64f7-49f2-a522-63f3ff81af91</NOTE>
    <NOTE Label="FourthCategory">5c826f70-388b-443d-a9b0-e5da21b85584</NOTE>

I needed to grab the value of the attribute Name from the <CONTAINER> element and the inner text of any <NOTE> element for which the attribute Label was set to FourthCategory.

No explanation this time, as the code is really simple. In fact, we’ve already seen what the -join and -eq operators do. Add a couple of foreach et voilà:

foreach ($c in $res.xml.CONTAINER) {
  foreach ($a in $c.NOTES) {
    $el = $a.note | Where { $_.Label -eq "FourthCategory" }
  $c.Name,$el."#text" -join ","

Running Coded-UI automated tests from the command line

Short and concise post, more like a memory aid for myself, about running Coded-UI tests without the need of the Visual Studio GUI. Disclaimer: I’m talking about VS 2012 (though this may apply to VS 2010 too).

According to MSDN,

MSTest is used to run load test in Visual Studio 2012. By default, unit tests and coded UI tests use VSTest.Console.exe in Visual Studio 2012. However, MSTest is used for compatibility with test projects created using Visual Studio 2010, or if a .testsettings file is manually added to a Visual Studio 2012 solution containing a unit test project, or coded UI test project.

Indeed you can run Coded-UI tests from the VS 2012 command prompt, by simply issuing VSTest.Console.exe NameOfYourTestSuite.dll. However, you could do the same by issuing MSTest.exe NameOfYourTestSuite.dll without the need of a .testsettings file.

It goes without saying, beware that if you try running your tests using MSTest from within a VS 2010 prompt, you’ll most likely end up having the command whinging like this: Unable to load the test container 'NameOfYourTestSuite.dll' or one of its dependencies. Error details: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.VisualStudio.TestTools.UITesting, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

That said, if you want to be able to run similar tests on a machine that does not have VS 2012 installed, you just need to download the Agents for Visual Studio 2012.

String manipulation from Python to PowerShell

Having spent most of my time so far in Python and Bash, it feels quite natural for me to try and find equivalent commands to the ones I used to use. Here’s a very brief list.

Even though PowerShell’s strong point is working with objects, I need from time to time to split or join strings. In Python both functions are methods of the string object (which, in the case of join, made me a little perplexed in the beginning). InPowerShell, they are both operators. To put it in practice, Python’s "a_b_c".split("_") and "+".join(["a","b","c"]) become "a_b_c" -split "_" and "a","b","c" -join "+", respectively, in PowerShell. Must say, in this case, I like PowerShell syntax better as far as clarity is concerned.

However, in Powershell, both join and split can also be used as unary operators – rather confusingly. That’s to say, if you don’t need to specify any argument (such as the delimeter as we did above) you could use the operators as follows: -split "a b c" and -join ("a","b","c"). Mind the parentheses! See for yourself what happens if you omit them, and check help about_join to get an explanation.

String formatting is another task I do on a regular basis. "{0} is {1}".format("learning","fun") is one of Python’s ways to do that (although it can become much more complex) and, quite conveniently, this is the PowerShell way: "{0} is {1}" -f "learning","fun". Not really that different, uh?

Another relatively common task is type casting. Say you want to cast a number as string. In Python you’d do str(42), in PowerShell you’ll type 42 -as [string] (or the convenient shorthand [string]42).

Enough for today, next time objects finally!

This is part of a series of posts on PowerShell. Some of these tips come from the book “PowerShell in Depth“.

-in: an alternative approach to -contains

A very short follow-up of the post about -contains and -like.

Newly added in PowerShell v3, there is an operator which mirrors what -contains does. This operator is -in. Python users will feel at home here, as the syntax is precisely the same, exception made for the usual dash that precedes all operators in PowerShell.

The final result is the same, whether you decide to go for -contains or for -in. The only difference is that, with the former you test whether a collection includes a value whereas with the latter you check if an element is included in a collection.

-like -contains? I still have to get used

In my journey to learning PowerShell I’ve stumbled upon -like and -contains, which are comparison operators.

-like is used to look for string matches and allows you to use wildcard characters like * (one or more characters) and ? (exactly one character). For instance, to look if the string test matches the string ThisTest, all I have to type is "ThisTest" -like "*test*", which is true. Likewise, both "ThisTest" -like "*test" and "ThisTest" -like "????test" return True.

I can’t hide the fact I’m pretty intrigued by the fact there’s no direct equivalent in Bash. The closest thing to -like I can think of on a Unix’ is grep – which is a command and not an operator. Speaking of which, grep-lovers should be aware that -like gives us a true value only if a full match happens. Therefore, "ThisTest" -like "test" evaluates to false.

The syntax for all comparison operators is the same: a -operator b. To be honest, for me this is logical for almost all operators (think -eq, -ge, etc.), but I still find it cumbersome to read when I use -like (or even -match): reading StringToSearch -like Pattern just doesn’t feel right.

The other operator, -contains, returns true if a collection contains the element on the right side of the operator. Easier shown than explained: "This","Test" -contains "test" is True. This works in a similar fashion to Python’s in operator. Again, though, discretion is advised. If we type "ThisTest" -contains "test" we’ll end up seeing False in the console. This is simply because, unlike in Python, strings are not collections.

A final note about the return value. We might expect all operators to return a Boolean value, but this is not always the case. Actually, quite the contrary: almost all comparison operators (that is, all but -contains and -is) return a Boolean value if the input to the operator (what’s on the left side) is a scalar. If we use a collection as input, then we are returned a list of matches. As an example: "This","Test","tesT" -contains "test" returns True but "This","Test","tesT" -like "test" returns Test tesT.

To know more, don’t forget to check the documentation: help about_comparisonOperators.

This is part of a series of posts on PowerShell. Some of these tips come from the book “PowerShell in Depth“.

Learn-Syntax, a.k.a the verb-noun pattern for PowerShell cmdlets

If you’ve poked a little bit with PowerShell, you might have noticed a recurring pattern for command names. The pattern is called “verb-noun” and is followed by each cmdlet, that is, commands internal to PowerShell written in a .NET language – see for example Get-Help, Select-Object.

The list of Microsoft approved verbs can be retrieved by typing, surprise surprise, Get-Verb in the console. It’s also good to notice that:

  • There’s always a dash between the verb and the noun
  • The noun is always singular
  • Other products generally prefix the noun with something specific string (SQL for SQL, AD for ActiveDirectory, …)
  • Nouns are not abbreviated
  • PowerShell is not case-sensitive but all verbs and nouns are Capitalised (increases readability)

Initially I thought that the last choice was a bit controversial. In Bash you can find plenty of short names for commands (think ls, du, df, …) and I admit they’re quite convenient. On the other hand, given a finite – and luckily not so vast – set of verbs, it can actually be easy to guess the name of a command. Want to get a the date? Maybe Get-Date is just what you’re looking for! [Disclaimer: it’s not always that easy… I don’t know you, but Read-Host and Get-ChildItem are not exactly what I’d come up with if I looked for the equivalent of read or ls in Bash!]

Aliases can also be defined (for both cmdlets and functions) via the Set-Alias cmdlet. The big difference with Bash is that PowerShell aliases cannot include any parameter, which means there’s no way to set ll to be the alias of ls -l. However, you can always define a function, which is what happens with Get-Help and help.

As for cmdlet parameters:

  • They are always preceded by a dash
  • They use CamelCase (although, again, PowerShell itself doesn’t care too much)
  • They might be positional, optional, mandatory – you can find all such information by querying for help on a particular parameter: try Get-Help Get-Date -Parameter Format
  • You don’t have to type a parameter name fully, just the number of characters that make it unique (example: Get-Date -Format "%d" and Get-Date -f "%d" are the same)
  •  <TAB> auto-completion works for parameters too (pr0 tip: type just - and hit <TAB>)

Finally, some characters that need special attention:

  • semicolons are used to separate commands on the same line (much like in Bash and Python)
  • curly braces delimit script blocks (we’ll get to these in another post)
  • the pipe character is used to redirect the output
  • the backtick is the escape character

This is part of a series of posts on PowerShell. Some of these tips come from the book “PowerShell in Depth“.

Get-Help! (In PowerShell)

Let’s get to the meaty part before delving into the nitty gritty details: PowerShell has got a rather comprehensive documentation, that can be access through Get-Help. This should be enough for you to get started, but if you want to know more, read on!

You can also type help and you’ll see you get to the same result. The only difference is, Get-Help is an internal command (so-called cmdlet) whereas help is a function that calls Get-Help and redirects the output through a pager (more). And you’ve also got man which is nothing but an alias for help to aid penguin lovers use the shell :)

Get-Help supports the wildcard * which is indeed useful to find matches in all the docs installed. If a single result comes back, that help page is displayed. If the search parameter matches more than two pages, a list is displayed in the console.

Once you’ve found the page of interest you can run the command against that document. However, at times you might want to use some parameters to get different results:

  • -Examples returns a list of examples on how to use the command in question
  • -Detailed gives you the detailed list of all the parameters the command supports
  • -Full gives you both examples and details

Do not forget to check out also the “about” files. They form a collection of documents the name of which always starts with about_ and discuss general matters (the use of While, …). Here’s a pointer to increase your appetite for knowledge: Get-Help about*.

On PowerShell version 3 the documentation is not installed by default. The main reason is that documentation can get old quite quickly and retrieving it when you need it is the best way to ensure you’ve got the freshest news. Update-Help as administrator is what you have to do to get it the first time and to update it afterwards.

This is part of a series of posts on PowerShell. Some of these tips come from the book “PowerShell in Depth“.

First steps in PowerShell

Personally, I tend to resort to my two most favourite tools, Bash (Cygwin) and Python, to automate some of my day-to-day testing tasks.

As I work with Windows systems, I admit both options are suboptimal, especially because they’re not installed by default. Also, the fact that PowerShell is object-oriented, makes it more suitable for some tasks with respect to the other options available. [Disclaimer: I strongly believe there is no “my tool is bigger better than yours” thing and I do not want to convince those who think along those lines. If you’re happy with what you have, I’m happy for you. Move along.]

That’s why recently I’ve started to look into the magic realm of PowerShell. Here I list some information that got me move my first steps – hopefully they’ll be of use to all who embark on a similar journey:

  • Windows 8 and Windows Server 2012 have PowerShell v3 installed by default. Windows 7 and Server 2008 shave got version 2
  • You can choose to use one of the two hosts that come with Windows: the console and the Integrated Scripting Environment (ISE)
  • The console, being based on the same software used for the command prompt, suffers from some limitations – for instance, it can’t display double byte charsets. The ISE can, and it’s got some other advantages, like the ability to display TrueType fonts, and to have multiple PowerShell sessions as tabs. On the other hand, the ISE is not installed by default on Server OSs
  • If you type powershell in the command prompt or cmd or in the PowerShell console you switch instantly from one to the other system
  • In Console, if you press F7 you can see the command history as a popup window. Get-History gives you access to another buffer where commands are recorded.
  • Just like for the command prompt, clicking on the icon in the top left corner of the console window allows you to set your preferences for the window (buffer history, command duplication, height and width, colour, among the most commonly used)
  • The <TAB> key gives you auto-completion
  • Start-Transcript not only logs your command history as you type (like %logstart in IPython) but also records the output for most commands (legacy commands like ping do not have their output recorded). Stop-Transcript clearly stops the logging

This is part of a series of posts on PowerShell. Some of these tips come from the book “PowerShell in Depth“, which I absolutely recommend.

Casual testing of everyday tools – or why people get angry

A decent example of overcomplicated interface

A decent example of overcomplicated interface

Meet KX-TS580EX, a landline phone I’ve recently had to set up for a friend of mine. I’ll refrain from talking about the design, which, to me is not appealing, and go directly to the point instead. Functionality – or better, lack thereof.

Open up the picture, and you’ll notice the display says to set the clock. Now, have a closer look and tell me what action you’d perform to do that, assuming you’ve got no access to the device manual.

I’d look for a menu button, and, failing that, a clock button. To be precise, I’d also look for icons resembling such two functions. Nope, there’s nothing like that. So, the following step would be to decipher all the icons, and see which ones might be related. Here’s what you’ve got (top to bottom, left to right): a key, a 90-deg bent arrow on top of a straight line, “R”, something in between “a steering wheel” and the Mazda logo, the MasterCard logo, a loudspeaker, an arrow pointing to the center of a square, an arrow exiting from the center of a square, the mute sign (although I must admit I know it only because I saw it somewhere else), OK, and a couple of other icons we already are acquainted with.

Now, it turns out the menu is activated by pressing the button with the arrow pointing to the center of a square, probably indicating some kind of “entering”. Intuitive? Not at all. Not for me, and I bet, not for many other people. And I bet, those many other people get angry at the phone itself for that.

But we could go even further. Say, why do some buttons have icons on and above them? How do you access one or the other functions? Depending on the context? Or holding the button for a few second? What’s the steering wheel icon about? And what’s the MasterCard-like one instead? Why choosing an icon which is quite difficult to read to set up call deviation (it’s the second one from the top)? Why going for the obscure “mute” icon? Isn’t there anything more intuitive?

What’s the bottom line here? Two things to take away. First, keep it simple, stupid. Choose complex over complicated. Less is more. Second, as a tester, you’re responsible with the product as a whole. If you think it can be done better, if you believe some annoyances can be polished away, speak up and make sure to inform who needs to be notified. Just report it and motivate it. Worst case scenario it will be just a Wontfix.

Silly policies for the greater good might be not good at all

Documentation overload? – © by Frank Jepsen

There’s a policy at work: technical support cannot hand anything that comes from clients to testers or developers. Anything includes databases, configuration files, logins & password, and so forth.

While the aim is undoubtedly right, to protect clients’ privacy, the whole matter is totally pointless, not to say harmful.

Pointless because anyone, upon joining, signs a contract that explicitly says that disclosing any sensitive information is strictly forbidden. Adding an extra level of enforcement is far from being useful.

Harmful because it goes against testers and devs, by hindering their jobs. Ultimately, they are those who solve the problem for the client.

Share your data within your organisation!