-
Notifications
You must be signed in to change notification settings - Fork 334
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
Add tests for input macro #478
Conversation
d311bf5
to
c13f2fb
Compare
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.
Generally looking really good, though there's a couple of things that I think might want another look.
it('renders with label', () => { | ||
const { $ } = render('input', examples.default) | ||
const $label = $('.govuk-c-label') | ||
expect($label.text()).toContain('National Insurance number') |
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.
Should we have a test that the label is associated by id
/ for
?
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.
Oh, we do, but it's further up. What's the thinking being splitting these up into a separate context?
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.
From line 97 I tested the examples that we have defined in the yaml
to somehow make sure we're not breaking them. Before that line are 'by default' tests that cover the arguments, logic and relationships.
it('renders with id', () => { | ||
const { $ } = render('input', { | ||
id: 'my-input', | ||
name: 'my-input-name' |
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.
We don't test for name, and given that in the example above we omit both id and name, do we want to do the same here and just provide an id
? Conversely, if we're providing name
and id
in the other examples because they are 'required', should we include them in the classes example also?
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.
Indeed I started to add id
and name
because they are 'required', but I'm not sure it's the right approach and right now is inconsistent across examples. I would rather add the minimum number of attributes since we cannot really enforce the 'required' state.
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.
Removed unused attributes for now, even if defined as 'required'.
c13f2fb
to
b4607fd
Compare
b4607fd
to
ac6707c
Compare
expect($label.attr('for')).toEqual('my-input') | ||
}) | ||
|
||
it('renders with error message', () => { |
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.
Would it make sense to split this test into two parts?
- it applies the error variant class if an error message is passed
- it renders an error message if passed
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.
split
|
||
it('renders with label', () => { | ||
const { $ } = render('input', { | ||
id: 'my-input', |
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.
This is redundant
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.
removed the other one that was testing the example and the label too
it('renders with attributes', () => { | ||
const { $ } = render('input', { | ||
attributes: { | ||
'aria-describedby': 'my-label' |
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 worth using a different 'non-sensical' data attribute, only to avoid confusion for people scanning through who might mis-read this as inputs actually having or requiring some aria markup?
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.
replaced aria-describedby
with 'non-sensical' data attribute
|
||
const $label = $('.govuk-c-label') | ||
expect($label).toBeTruthy() | ||
expect($label.attr('for')).toEqual('my-input') |
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.
Again, suggest this is split into two parts - one that tests that the label is rendered correctly (probably worth checking the text itself rather than just ensuring the element exists?) and a second test that ensures the label is correctly associated with the input?
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 expect the label to be tested within the label macro. We don't add any logic about the label in the input macro, except for setting label's for
attribute equal to the input's id
.
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.
OK. I still think it's worth having an explicit test for that for/id relationship.
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.
split
it('renders with hint text', () => { | ||
const { $ } = render('input', examples['with-hint-text']) | ||
const $hintText = $('.govuk-c-label__hint') | ||
expect($hintText.text().trim()).toEqual('It’s on your National Insurance card, benefit letter, payslip or P60. For example, ‘QQ 12 34 56 C’.') |
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.
Would be good to wrap this within 80 chars.
ac6707c
to
1284fd9
Compare
1284fd9
to
4d5edfb
Compare
4d5edfb
to
84a9c5c
Compare
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.
Looks good to me. Thanks for talking me through the rationale of how we're grouping tests @alex-ju (I'll write these up for our docs).
I don't know if you want to have another look at this PR @36degrees before it gets merged?
84a9c5c
to
04370bf
Compare
}) | ||
|
||
const $errorMessage = $('.govuk-c-error-message') | ||
expect($errorMessage).toBeTruthy() |
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.
Could we replace these truthy tests with snapshots?
04370bf
to
f5773be
Compare
Updated with snapshots as discussed. |
} | ||
}) | ||
|
||
expect(htmlWithClassName($, '.govuk-c-label')).toMatchSnapshot() |
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.
Could we wrap these snapshots tests with a description 'dependant components' or similar?
f5773be
to
826947d
Compare
This PR:
Note to reviewers: if you feel like any example should be removed, let me know.
Trello Card