Skip to content
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

Merged
merged 31 commits into from
Nov 17, 2020
Merged

Exercise2 #4

merged 31 commits into from
Nov 17, 2020

Conversation

jobegrabber
Copy link
Collaborator

No description provided.

@s0557917
Copy link

s0557917 commented Nov 9, 2020

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.
Hope this helps, cheers! 😀

P.S. habe euch zu Reviewers in unser Repo gesetzt, hoffe das ist jetzt in Ordnung.

@jobegrabber
Copy link
Collaborator Author

jobegrabber commented Nov 9, 2020

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.
Hope this helps, cheers! grinning

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 main and rebase on that!
EDIT: Done.

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.
If you didn't find a group to get a review from I think you should approach @medizinmensch and @roschaefer first.

@jobegrabber jobegrabber marked this pull request as ready for review November 9, 2020 21:58
@s0557917
Copy link

s0557917 commented Nov 9, 2020

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.
Hope this helps, cheers! grinning
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 main and rebase on that!
EDIT: Done.

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.
If you didn't find a group to get a review from I think you should approach @medizinmensch and @roschaefer first.

Allright, thanks! I'll ask around then.

@jobegrabber jobegrabber requested review from s0557917 and powlaa and removed request for s0557917 November 10, 2020 09:07
@donatbrzoska donatbrzoska requested a review from noeljns November 10, 2020 18:24

strategy:
matrix:
node-version: [10.x, 12.x, 14.x]
Copy link

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@roschaefer roschaefer Nov 18, 2020

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.

webapp/dojo_news/src/App.spec.js Outdated Show resolved Hide resolved
Copy link

@powlaa powlaa left a 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)

README.md Show resolved Hide resolved
Comment on lines 31 to 64
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);
});
});
Copy link

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.

Copy link
Contributor

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

Copy link
Contributor

@donatbrzoska donatbrzoska Nov 15, 2020

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?

Copy link
Contributor

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/

Screenshot - 2020-11-15T140650 199

But yes, I like your idea of structuring your tests by feature.

  News list
    emty state
      is displayed when list items are empty

Copy link
Contributor

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.

webapp/dojo_news/src/App.vue Show resolved Hide resolved
Copy link
Contributor

@roschaefer roschaefer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perfect

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!

README.md Show resolved Hide resolved
webapp/dojo_news/src/App.spec.js Outdated Show resolved Hide resolved
webapp/dojo_news/src/App.spec.js Outdated Show resolved Hide resolved
webapp/dojo_news/src/App.spec.js Outdated Show resolved Hide resolved
webapp/dojo_news/src/App.spec.js Outdated Show resolved Hide resolved
webapp/dojo_news/src/App.spec.js Outdated Show resolved Hide resolved

let expectedIdList = [1, 0, 2, 3];
// or check HTML
let actualIdList = wrapper.vm.sortedNewsListItems.map(x => x.id);
Copy link
Contributor

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.

Copy link
Contributor

@donatbrzoska donatbrzoska Nov 15, 2020

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!

Copy link
Contributor

@roschaefer roschaefer Nov 15, 2020

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)'])

webapp/dojo_news/src/App.spec.js Outdated Show resolved Hide resolved
webapp/dojo_news/src/App.vue Outdated Show resolved Hide resolved
webapp/dojo_news/src/App.vue Show resolved Hide resolved
@jobegrabber jobegrabber merged commit de87365 into main Nov 17, 2020
@jobegrabber jobegrabber deleted the exercise2 branch November 17, 2020 21:03
jobegrabber pushed a commit that referenced this pull request Dec 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants