David Jimenez

How do you know that your code works? Traditionally, there have been two options: you can prove it using mathematics; or you can write tests to show that despite your best effort you cannot break it.

Proving vs Testing

In Postman, environment nested variables look something like this:
<img src="/images/postman-nested-variables/postman-nested-variable.png" alt="Nested variable">
The variable {{mock_url}} contains another one, {{environment}}.
{{environment}} defines the subdomain for the URL that we are using in our tests. In the code snippet below, we see that Postman correctly resolved the nested variable to generate a URL with the <code>development</code> subdomain:
<img src="/images/postman-nested-variables/code-snippet.png" alt="Code snippet">
Why would we want to do this?
Many organizations test and release their code using different environments. Three common environments are development, staging, and production. Nested variables could be good way to run a collection against the appropriate target.
Could this be done in other ways? Certainly. We can introduce more variables:
<img src="/images/postman-nested-variables/multi-variable.png" alt="Multiple variables">
Instead of having a single variable containing the whole URL, we could have two: one for the environment; the other, for the domain. However, what would happen if we use the URL extension, rather than the subdomain, to distiguish between environments? If we were starting from scratch, we could introduce a third variable. But what if we already have several collections with multiple endpoints that only use the first two variables we defined?

Postman environment variables can actually contain other variables.  In this post we explore how to leverage this feature, and discuss possible use cases.

Nested environment variables in Postman

Access modifiers control whether a type (e.g., a class), or one of its properties can be used by other code.  A public class, for instance, can be used by any code in any assembly.  In this post we explore how the internal access modifier can provide a mechanism for enforcing boundaries in our architecture.