2

I am currently writing REST API automation test scripts. As most of the research article suggests that we should write DAMP (Descriptive And Meaningful Phrases) tests that promote readability. However, I feel that there are a lot of duplicate codes in my tests and in an attempt to remove the duplicates I end up with 'DRY' (Don't repeat yourself) code which tends to dependency tests. So I am a bit confused about which approach to use? I would really appreciate it If anyone can give me some suggestions on this?

Sathish
  • 350
  • 3
  • 24

2 Answers2

2

A general rule is to keep the code related to the Test Objective DAMP, having everything else DRY. To simplify the rule, code related to the Test Objective may reference to:

  • Actions that DIRECTLY impact the expected result

  • Data parameters that DIRECTLY affect the expected result

Code NOT related to the Test Objective may reference to:

  • Actions that do not impact the expected result DIRECTLY (Example: authorization for the tests not related to login)

  • Configuration data and data parameters that does not affect the expected results DIRECTLY (Example: Base URL, login and password for the tests not related to authorization)

Anatoliy Sakhno
  • 146
  • 1
  • 7
1

My recommendations are:

  • re-use payloads (JSON or XML) from files where possible
  • sign-in flows that set an Authorization header should be re-usable
  • do not combine API requests to different end-points into a re-usable Scenario
  • even for the same end-point, for very different payloads (e.g. boundary / error conditions) use a separate Scenario for each
  • use Scenario Outlines for data-driven tests

Also please refer this answer for a good example of what NOT to do: https://stackoverflow.com/a/54126724/143475

Peter Thomas
  • 54,465
  • 21
  • 84
  • 248