-
Notifications
You must be signed in to change notification settings - Fork 6.8k
feat(datepicker/testing): add test harnesses for the datepicker module #20219
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
Conversation
import {MatCalendarHarness} from './calendar-harness'; | ||
|
||
/** Interface for a test harness that can open and close a calendar. */ | ||
export interface DatepickerTrigger { |
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'm not super happy with how this one turned out, but this is the best way I found to implement it. The problem is that these harnesses all have 2 base classes: an input and a datepicker trigger. The input is extended by MatDatepickerInput
, MatStartDate
and MatEndDate
, whereas the trigger needs to be extended by MatDatepickerInput
, MatDateRangeInput
and MatDatepickerToggle
. Initially I had the input base class extend the trigger, but the trigger behavior doesn't make sense on MatStartDate
and MatEndDate
. I tried to use a mixin so that MatDatepickerInput
can extend both base classes, but TS kept complaining about the mixin class having the protected methods coming from ComponentHarness
.
I ended up with this which has an interface that enforces that MatDatepickerInput
and the classes extending the trigger base class are all consistent while having the trickier shared logic in functions.
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 think that's totally reasonable
import {MatCalendarHarness} from './calendar-harness'; | ||
|
||
/** Interface for a test harness that can open and close a calendar. */ | ||
export interface DatepickerTrigger { |
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 think that's totally reasonable
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.
LGTM
@mmalerba should also take a look
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.
LGTM
* Sets up test harnesses for the components in the datepicker module. Includes datepicker input, datepicker toggle, calendar, calendar cell, date range input, date range input start/end sub-inputs. * Fixes an issue in `mat-calendar` that showed up while adding unit tests for the harnesses. The standalone calendar wasn't picking up changes to the comparison range after init. * Expands the dialog `backdropClass` signature to allow `string[]`. This was necessary for the harness so that we can tie a harness to a particular backdrop.
ea98d03
to
70872b9
Compare
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
mat-calendar
that showed up while adding unit tests for the harnesses. The standalone calendar wasn't picking up changes to the comparison range after init.backdropClass
signature to allowstring[]
. This was necessary for the harness so that we can tie a harness to a particular backdrop.