Lesson 9 - Applying what we've learned - Parameterize another check with TestCaseData

🙋 Questions
1

Title: Parameterize another check with TestCaseData

Time: 15-30 minutes

Purpose: To practice using TestCaseData, and explore other ideas for ways to parameterize our checks

Introduction: At the end of Lesson 9 I challenged you to parameterize another check that you’ve already written.

Activity:

  • Choose a check you’ve already written to parameterize

  • Determine what scenarios to check (use our automation plan or come up with your own)

    • Some ideas:
      • Modify the GET a single TodoItem check to check for a non-existent item also (with a NotFound response), and/or send a non-numeric character instead of the ID in the URL
      • Modify the POST check to check response codes if you send a TodoItem without a Name value (like we did with the PUT)

  • Some hints:

  • Write your check, and verify that it passes

  • Share on this thread:

    • What scenario(s) did you try?
    • Are you stuck anywhere?
2

Hi @g33klady

First all , thanks for providing this wonderful course.
I have found an issue, while implementing the delete method.
It returns MethodNotAllowed, instead of NoContent. Not sure what might cause this? could you please explain it? Thanks

3

Thank you @rushlinn!
Sorry you found an issue - let’s figure it out! Can you please share your code?
Thanks!

4

Even a test as simple as get by id can be parameterized:

public static IEnumerable GetByIdTestData
        {
            get
            {
                yield return new TestCaseData(1).Returns("OK").SetName("valid id");
                yield return new TestCaseData(2333).Returns("NotFound").SetName("nonexistent id");

                // this one should be tested differently (if we want it at all)
                yield return new TestCaseData("cda6932c-540e-401f-853c-da3f2feb6ea2").Returns("BadRequest").SetName("id not an integer");
            }
        }

Lessons learned:

  • parameterized tests are rigid (see above). Only parameters of the same data type.
  • don’t call all happy path tests “happy path”, rather have something more descriptive: “valid id”.
1 Like
5

Why does the Task have to return a string, if you can also make it return a HttpStatusCode. For me, this totally works:

[Test, TestCaseSource(typeof(TestDataClass), "GetByIdTestData")]
        public async Task<HttpStatusCode> VerifyGetById(long id)
        {
            // Arrange
            // ...

            // Act
            // ...

            return response.StatusCode;
        }

and

public static IEnumerable GetByIdTestData
        {
            get
            {
                yield return new TestCaseData(1).Returns(HttpStatusCode.OK).SetName("valid id");
                yield return new TestCaseData(2333).Returns(HttpStatusCode.NotFound).SetName("nonexistent id");
            }
        }
1 Like
6

Great catch! I like this implementation better than String

7

Hello, in the Lesson 9 parameterised check you changed the //Assert part from an Assert.AreEqual style-check which takes in expected and actual response codes 



 to a ‘return’ of only the response status code, and the PutTestData is returning the expected value per scenario - here I’m struggling to see which part of the code is now doing the actual check between response vs expected ?

Also, in the parameterised check is it easy to check more than one thing in the same Test? e.g. checking the properties / values coming back and the status code in a single tets - so if any one of those fails, the single Test fails. (Maybe I can have a go at this when I better understand the construction of the test :slight_smile: )

1 Like
8

Great question @simienrigler!
The part of the code that’s doing the actual check is within the TestCaseData - here’s some information from NUnit on that TestCaseSource | NUnit Docs.
I haven’t tried checking multiple items, but that link should be able to help you along if you’d like to try it out!