-
Notifications
You must be signed in to change notification settings - Fork 2
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
Exercise2 #4
Exercise2 #4
Conversation
091e75f
to
df5495f
Compare
Hey, the work for the current homework looks good, but if I saw correctly, you also added all the merged files from the homework repository to the PR. It is obviously not wrong, but it makes the list of files longer, making it a bit more tedious to check. It would be better, to either merge it directly with main or create a new branch for it, thus keeping the dedicated feature branch a bit cleaner. P.S. habe euch zu Reviewers in unser Repo gesetzt, hoffe das ist jetzt in Ordnung. |
Yes, thanks, we should merge the new exercise into We're peer-reviewing with team lichtow and are fairly constrained in terms of time available. Not sure if you picked the wrong group you wanted to request a review from. |
df5495f
to
9153cfa
Compare
Allright, thanks! I'll ask around then. |
|
||
strategy: | ||
matrix: | ||
node-version: [10.x, 12.x, 14.x] |
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.
Any reason why you choose three versions instead of specifying one?
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.
These are the three current LTS versions.
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.
On the other PRs I said one version would be enough as you have control over the node version: Either you on your laptop or your build server will transpile your VueJS code.
But no biggie.
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.
Overall I really like how you implemented all the tasks from exercise 2 👍
I'm not sure why but there seem to be a lot of files in 'archive/' that have been deleted and show up in the Files changed as well. (It was a bit annoying to click through them all when reviewing)
webapp/dojo_news/src/App.spec.js
Outdated
it('renders items correctly dependent on mutations of the list of NewsItems', async () => { | ||
const wrapper = shallowMount(App, { | ||
propsData: { | ||
initialNewsListItems: [ | ||
{id: 0, title: "macOS", votes: 0}, | ||
] | ||
} | ||
}); | ||
expect(wrapper.find("#newslist").html()).not.toBe('<div id="newslist"></div>'); | ||
expect(wrapper.findAll(".newslistitem").length).toBe(1); | ||
|
||
wrapper.vm.removeNewsListItem(0); | ||
|
||
await Vue.nextTick(); | ||
|
||
expect(wrapper.find("#newslist").html()).toBe('<div id="newslist"></div>'); | ||
expect(wrapper.findAll(".newslistitem").length).toBe(0); | ||
|
||
wrapper.vm.createNewsListItem("Test"); | ||
wrapper.vm.createNewsListItem("Test2"); | ||
|
||
await Vue.nextTick(); | ||
|
||
expect(wrapper.find("#newslist").html()).not.toBe('<div id="newslist"></div>'); | ||
expect(wrapper.findAll(".newslistitem").length).toBe(2); | ||
}); | ||
}); |
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.
There are 2 things that are being tested here, adding items and removing items. I think it would be better to separate those into two test cases so that it will be more clear where a test fails.
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.
Yes, and also DRY your test case descriptions a bit:
News list
✓ does not render any items on an initially empty list of NewsItems (29 ms)
✓ renders items on an initially filled list of NewsItems (8 ms)
✓ renders items correctly dependent on mutations of the list of NewsItems (12 ms)
List Empty Message
✓ displays a message on an initially empty list of NewsItems (3 ms)
✓ displays no message on an initially non-empty list of NewsItems (4 ms)
✓ adds and removes the message on list mutations (6 ms)
Reverse Order Button
✓ list order is reversed upon Reverse-Button click from initial state _descending_ (8 ms)
✓ list order is reversed upon Reverse-Button click from initial state _ascending_ (6 ms)
✓ displays the Reverse-Order-Button on an initially non empty list of NewsItems (5 ms)
✓ does not display the Reverse-Order-Button on an initially empty list of NewsItems (4 ms)
✓ Reverse-Button is hidden upon empty list (6 ms)
✓ Reverse-Button shows up again upon non-empty list (6 ms)
What about something like:
News list
given no items
renders empty 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.
While I agree with you on writing two seperate tests for two functionalities (got that fixed in the meantime), I think the structure of the tests is more of a personal preference thing. We structured our tests by feature, so we add the state to each of the test case titles. You would structure it by state, but then we would have to add the feature title to it. Or is there any other reason for our version to be bad practice?
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.
Just make sure your test case descriptions are documenting the behaviour of your code well. It's always a little tricky because it depends on the perception of humans.
I draw lot of my knowledge from sites like https://www.betterspecs.org/
But yes, I like your idea of structuring your tests by feature.
News list
emty state
is displayed when list items are empty
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 definitely see your point, it's a dream to be able to read code and/or test results like that. I renamed all the test cases for a better reading experience of the npm run test:unit
output.
But I still think that adding another description layer would be too verbose in this case. Because for example, you would have the description "given no items" for every feature, just for one test case. And if I were to do it like that, I also had to add the descriptions "given items", "upon empty news list" and "upon non-empty news list". Everywhere, just for one test case, which in my eyes ist way too verbose.
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.
Your PR is close to perfect. Only your test cases and implementation could be improved, see my suggestions below.
You got all 9 ⭐ plus one ⭐ for your review here https://media.giphy.com/media/l2Sq5GffrCyUMEXjW/giphy.gif
That's 10/10 ⭐ well done!
webapp/dojo_news/src/App.spec.js
Outdated
|
||
let expectedIdList = [1, 0, 2, 3]; | ||
// or check HTML | ||
let actualIdList = wrapper.vm.sortedNewsListItems.map(x => x.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.
Here you're testing against the internal propertysortedNewsListItems
and not what's being rendered. This puts you under a high risk of false-negatives.
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 tried to fix that but it's a pretty ugly solution in my opinion. I am testing against the wrapper.find("newslist").element.innerHTML
. It feels very wrong because I obtained the "correct" string by printing this exact thing and looking through it for possible errors. And this is still not the final string that actually gets rendered by the browser ... Do you have a better way of doing this in mind?
EDIT: We found another way, commit coming soon!
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.
expect(wrapper.findAllComponents(NewsItem).wrappers.map(w => w.text()))
.toEqual(['Title a (2)', 'Title b (1)'])
e9104ed
to
cebc3bf
Compare
Co-authored-by: Robert Schäfer <[email protected]>
Co-authored-by: Robert Schäfer <[email protected]>
Co-authored-by: Robert Schäfer <[email protected]>
14c2886
to
fa39e58
Compare
No description provided.