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

Post a Comment

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...
Post a Comment
Read more

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 ...
Post a Comment
Read more

Monitoring and Observability

In this post I am going to talk about monitoring and observability. Now what are monitoring and observability? Monitoring is defined as….. "to watch and check a situation carefully for a period of time in order to discover something about it" From <https://dictionary.cambridge.org/dictionary/english/monitoring> Observability is defined as….. "to watch carefully the way something happens or the way someone does something, especially in order to learn more about it" From <https://dictionary.cambridge.org/dictionary/english/observe?q=Observing> So the main difference between the 2 is that one is around checking to discover something whilst the other is about watching something in order to learn more about it. Why are both important? They are both important as they can tell us different things about a system and can provide us with information that can feed into decisions and actions that can be made both now and in the future to improve software quality as ...
Post a Comment
Read more