-
Notifications
You must be signed in to change notification settings - Fork 278
Support passing arguments to DynamicData methods #5892
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
test/UnitTests/MSTest.SelfRealExamples.UnitTests/DynamicDataMethodArgumentsTests.cs
Outdated
Show resolved
Hide resolved
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5892 +/- ##
==========================================
- Coverage 73.32% 73.31% -0.01%
==========================================
Files 613 613
Lines 37574 37636 +62
==========================================
+ Hits 27552 27594 +42
- Misses 10022 10042 +20
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
=> Assert.IsInRange(4, 6, a); | ||
|
||
[TestMethod] | ||
[DynamicData(nameof(GetData2), [new int[] { 4, 5, 6 }])] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it might be good to add tests for the multiple parameter case and also for object[] parameter case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at DataRow tests, we probably want:
- 1 value
- few values
- tuple
- string[]
- object[]
And a case where the data member declares parameters with params
(whether or not we support it).
It's probably also good if we have an acceptance test asserting logs + test didn't run for invalid input cases (too few, too many, invalid type args).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Evangelink Just to be clear, do we want to make it special case params
(ParamArrayAttribute
)? Similar to here? Or just treat it as object[]
, in that case it's no different from any other parameter? Or probably block the usage of params
until we make a decision?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whatever is easier. I am not a big fan of params but I know some people are using it. Given this is a new feature, we are quite free and I am perfectly fine to wait for feedback. On the other hand, if that's "easy" to do, it's probably better to have similarity in all places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll disallow params for now.
using System.Collections.Generic; | ||
using Microsoft.VisualStudio.TestTools.UnitTesting; | ||
[TestClass] | ||
public class MyTestClass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a test for a failing scenario? where we do pass in the incorrect number of parameters?
6c339cf
to
90e0908
Compare
Fixes #1510