Datarow tests - support methods with optional parameters and add params support

[ssa3512]

Resolves #252

[Microsoft Contribution License Agreements (msftclas)]

All CLA requirements met.

[Jayarani garg (jayaranigarg)]

ssa3512 : Thank you for your contribution!!
PR looks good overall. Kindly do the needful changes so that we can push this in.

[Jayarani garg (jayaranigarg)]

ssa3512 : It would be even more wonderful if you can address this related issue #283 as well as part of this change.

[Jayarani garg (jayaranigarg)]

ssa3512 : Any updates on this? Let us know if you need some help on this.

[ssa3512]

Jayarani garg (@jayaranigarg) sorry, no updates yet. I'm hoping to have some time to address the feedback and look at including #283 early next week.

[ssa3512]

Jayarani garg (@jayaranigarg) I believe I addressed all feedback; should now resolve #283 as well. Please review again and let me know if anything else needs to be addressed.

[Jayarani garg (jayaranigarg)]

ssa3512 : Awesome work 👍 Left few minor comments, please address them and we should be all good to push this in.

[ssa3512]

Jayarani garg (@jayaranigarg) if we remove the overridden tests from DerivedClass, the E2E tests run the base class tests twice - once for BaseClass and once for DerivedClass, causing the counts of passed tests to be doubled. Is it okay to specify FullyQualifiedName~BaseClass in the testCaseFilter for the new E2E tests to prevent this, causing only the base class to run, or should I break the new tests out into a separate DataRowTest class that does not have a derived class?

[Jayarani garg (jayaranigarg)]

Jayarani garg (@jayaranigarg) if we remove the overridden tests from DerivedClass, the E2E tests run the base class tests twice - once for BaseClass and once for DerivedClass, causing the counts of passed tests to be doubled. Is it okay to specify FullyQualifiedName~BaseClass in the testCaseFilter for the new E2E tests to prevent this, causing only the base class to run, or should I break the new tests out into a separate DataRowTest class that does not have a derived class?

ssa3512 : Oh I see. I believe if we just keep these tests in the derived class, then they should not be executed twice.

[ssa3512]

ssa3512 : Oh I see. I believe if we just keep these tests in the derived class, then they should not be executed twice.

Jayarani garg (@jayaranigarg) In that case is everything good to go?

[Jayarani garg (jayaranigarg)]

ssa3512 : I have updated my comments. You can remove the tests from the base class and have them in derived class only. It will be good to go after that.

[ssa3512]

Jayarani garg (@jayaranigarg) removed tests from base class and added the [DataRow()] tests that were only in base to Derived

[Jayarani garg (jayaranigarg)]

ssa3512 : Looks nice🎉 I will go ahead and push this in. Thank you for the contributions 🥇

[Jonas Nyrup (jnyrup)]

Jayarani garg (@jayaranigarg) Should #283 be closed as well?

[Jayarani garg (jayaranigarg)]

Jonas Nyrup (@jnyrup): Yes. This PR adds support for params as well. Updated the title to be more explicit.

[Juliano Leal Goncalves (julealgon)]

params support is completely unrelated to supporting default parameter values.

I'd suggest updating the release notes to make it clear that params is also supported on 2.0.0 now. The current release notes doesn't mention it at all, I assume because it only keeps track of issues, and we didn't have an issue to track this part of the work here:

In the future, I'd suggest being mindful of these changes and:

1. Sending them in separate PRs to promote isolation of changes
2. Ensuring that all functional changes are covered by an issue item for tracking

EDIT: Looks like there was a specific issue to track the params part, but we forgot to close it in time to generate the release?