The SQA2 Blog: BBT - How To
Parameterization isn’t a new concept only in BBT, in fact BDD has the same capability. Where BDD uses quotes in their steps to specify specific string values to use as a parameter, BBT uses curly braces. Now what does that mean to use parameterization? In many cases, you can use the same step but with a different value. For example “I logins in with my {accountType} account.” This provides the option of adding many different values to accountType. It could be an admin account or a guest account, all these possibilities can be fed to that single step. It’s important to note that curly brace values are purely visual. The setting of actual parameters happens within the steps themselves.
Diving Deeper into Parameterization
Okay, that’s the basics. Let’s dive a bit deeper to understand how it works in the BBT tool. When you create a node with a curly brace parameter, you’re asking the tool to provide the value for that key; the string within the curly braces. So when you generate test cases later, it will fill in that key with the correct value. The way this value is set is through true, false, or parameter tables. For the purpose of just understanding parameterization, I’ll focus on only the true state table. This table is available in any context or outcome, and the key is set by the column names and the value is set by providing a value in the row or rows below that column.
The key value pair is stored in memory whenever running a test case. Which means you have access to it throughout the entirety of that test. Meaning, if you set a key value pair in a context, you can display the value of that key in your outcome without having to set up any columns or rows in the outcome, because that key value already exists in memory. There is a drawback to relying on whats in memory though. If the same key name is used again during the same test, the value is overridden. Only the latest set key value pair is accessible.