Skip to main content

How to deal with external data formats?

This blog post is in response to Challenge 7 of the #GivenWhenThenWithStyle blog post series with Gojko Adzic 

You can see what the challenge is here:

https://specflow.org/blog/how-to-deal-with-external-data-formats-givenwhenthenwithstyle/

Having the message format in the test would  (as mentioned in the challenge) look terrible and would be difficult to understand. 

If I was to rewrite this scenario I would do something like the following:

1) Write a test that tests the validity of the payment message. So something like

Scenario : payment message validity

Given an account EE382200221020145685 has a balance

When the system receives a payment message

Then the payment message is valid. 

I would store the actual payment message in another file as not to clutter the scenario file and this message would be passed into the test in the When

line. The Then part of the test could cover various areas, such as:

- All the correct tags are present 

- The xml is valid

2) I would then add another test to make sure that the payment status report is valid:

Given an account EE382200221020145685 has a balance

When the system receives the payment message

Then the payment report status is valid. 

3) I would then move onto testing the actual content of the message. I would speak to the business users and ask them what fields they really care about in the message and use them in my tests. So I would do something like this:

Scenario: Transactions in payments 

Given an account EE382200221020145685 has balance of 100.00 EUR

When the system receives the payment message with the following initiating party values

| MsgID      | CreditDateTime     | Payment| InitiatingPArty| 

| MSGID000002| 2020-07-28T10:33:56| 22.00  | Tom Nook       |

And the payment message has the following Payment information

| PaymentMethod| PaymentAmount|Payment Date| AccountIBAN          | FinancialINstitutionIDBIC| AccoumtIBAN         |

| TRF          | 22.00         |2020-07-28 | AT611904300234573201 | ABAGATWWXXX              | EE382200221020145685|

Then the following values are returned in the payment report status

|MsgID                  |CreditDateTime       | OriginalMessageID|

| STAT20200728103356001 | 2020-07-28T10:33:56 | MSGID000002      |


Writing the tests in the above way will enable more tests to be written by expanding the test to use Examples. Also If the message is an industry standard one the business users will probably know what they look like off of the top of their head. So the value of the tests is to make sure that the content in  important fields is correct not all of the fields in the messages. It also abstracts the message away from the tests in order to make them easier to read and focus the tests on whats important. The message can still be viewed as it would be stored in a file somewhere and a business users if they want could have a look at the file in which the message resides. 


Comments

Popular posts from this blog

How to deal with pauses and timeouts in specflow

So this blogpost is in response to the weekly Specflow blog posts and challenges that have been written by Gojko Adzic. This weeks challenge was how would you rewrite or rephrase the below scenario: Given a user registers successfully When the account page reloads And the user waits 2 seconds Then the account page displays "Account approved" My initial though was something like this: Given a user registers successfully  When the account page reloads   Then the account page is displayed within a satisfactory time period     And the account page displays "Account Approved" Now the problem with this scenario is what defines a satisfactory time? You could add it as a comment or in a scenario outline but over time the time a user waits could change and if this is updated in the code behind but the scenario outline or comments are not, then what the test does and what is described do not match - this would potentially cause issues in the future. My next ide...

Benchmarking in C# - Simple Job attribute

In this post I am going to continue my servies on BenchMarkDotNet and I will explain what the various parameters do that are present in the simplejob attribute.  Now I say all....... the documentation is not great so I will explain what 3 out of the 4 do :) So If you remember in my previous post I had a MyFirstBenchmark class which contained the details about the benchmark test that I wanted to run. In this class there is an attribute called SimpleJob and this attribute contains a few parameters that can be configured when you run a test.  By default BenchMarkDotNet will choose the number of iterations that will return the best precision. However, using the simplejob attribute allows you to quickly get a set of statistics. Below is how my test was setup: Now as you can see I had the following parameters in the SimpleJob attribute: launchCount - This parameter allows you to define how many times the benchmarking test is run warmupCount ...

Testing and Mindfulness

How aware are you? Do you live in the here and now or is your mind always somewhere else? This blog post is about Mindfulness. Mindfulness is a simple meditation and is defined as (According to Wikipedia): "The intentional, accepting and non-judgemental focus of one's attention on the emotions, thoughts and sensations occurring in the present moment" Now Mindfulness has become more popular in the west in recent years as it has shown to have benefits for people who are suffering from Depression and Anxiety. It has been around for a while and is often thought to of originated from Buddhism and some people believe it started thousands of years ago. Now modern life is hectic and I’m sure we all have lots of things going on in our lives that keep our Brains busy and trying to focus on one thing at a time can be a challenge. I can't remember the number of times I've been doing something and my mind is somewhere else entirely. Mindfuln...