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

LabelService: create custom operator for label synchronisation #590

Merged
merged 23 commits into from
Feb 24, 2021
Merged

LabelService: create custom operator for label synchronisation #590

merged 23 commits into from
Feb 24, 2021

Conversation

seanlowjk
Copy link
Contributor

@seanlowjk seanlowjk commented Feb 11, 2021

Summary

This PR addresses part of #549 , which abstracts the steps of sessionSetup() in PhaseService to readable, custom operators

Description

This PR does the following:

  1. Abstracts the logic of syncing of labels in the application with the remote repository labels into the syncLabels() method in LabelService
  2. Moves the error throwing as a readable step in sessionSetup() in PhaseService
  3. Adds basic tests for syncLabels() and checkSessionCreation()

Suggested Commit Message:

LabelService: create custom operator for label synchronisation

Let us shift the  label synchronization custom operator back to LabelService to 
facilitate readability in sessioNSetup().

We cam also add tests for this custom operator: to create: 
- all required labels to be created when no required labels are synchronized
- some required labels to be created when at least 1 required label is synchronized
- no required labels to be created when all the required labels are synchronized

To achieve this, we would need to 
- Keep the error handling  operator within PhaseService 
- Create a new custom operator syncLabels() to call upon synchronizeRemoteLabels()

@seanlowjk seanlowjk requested a review from a team February 15, 2021 11:22
Copy link
Contributor

@kkangs0226 kkangs0226 left a comment

Choose a reason for hiding this comment

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

Other than the comments I've left, it looks good to me!

src/app/core/services/repository.service.ts Outdated Show resolved Hide resolved

describe('RepositoryService', () => {
beforeEach(() => {
labelService = jasmine.createSpyObj('GithubService', ['synchronizeRemoteLabels']);
Copy link
Contributor

Choose a reason for hiding this comment

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

Can I just check why is it 'GithubService' for the spy object? Shouldn't it be 'labelService' instead? Let me know if my interpretation is correct😅

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh yes i made a typo! Thanks for pointing that out!!

@codecov-io
Copy link

codecov-io commented Feb 18, 2021

Codecov Report

Merging #590 (d59e8ce) into master (df9147b) will increase coverage by 0.50%.
The diff coverage is 75.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #590      +/-   ##
==========================================
+ Coverage   65.14%   65.65%   +0.50%     
==========================================
  Files          67       67              
  Lines        2106     2111       +5     
  Branches      199      198       -1     
==========================================
+ Hits         1372     1386      +14     
+ Misses        696      686      -10     
- Partials       38       39       +1     
Impacted Files Coverage Δ
src/app/core/services/phase.service.ts 54.54% <50.00%> (+1.67%) ⬆️
src/app/core/services/label.service.ts 78.02% <100.00%> (+7.90%) ⬆️
src/app/core/models/label.model.ts 90.00% <0.00%> (+20.00%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update df9147b...d59e8ce. Read the comment docs.

Copy link
Contributor

@ptvrajsk ptvrajsk left a comment

Choose a reason for hiding this comment

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

LGTM 👍 Just one question regarding the test case

Comment on lines 13 to 21
describe('.syncLabels()', () => {
it('should throw an error given an Observable of false', () => {
of(false)
.pipe(repositoryService.syncLabels())
.subscribe({
error: (err) =>
expect(err).toEqual(new Error(SESSION_AVALIABILITY_FIX_FAILED)),
});
});
Copy link
Contributor

Choose a reason for hiding this comment

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

A quick question cause I'm not entirely sure,
if we supply an of(true) does this test fail? Or do we need to supply the next: in the .subscribe()?

So like this? Just checking cause I'm not sure haha

it('should throw an error given an Observable of false', () => {
  of(false)
    .pipe(repositoryService.syncLabels())
    .subscribe({
      next: () => fail(),
      error: (err) => expect(err).toEqual(new Error(SESSION_AVALIABILITY_FIX_FAILED)),
  });
});

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yea, actually I just realised with the above, it would also pass the TC if i supply a value of true 😅
We would need to supply the next to ensure that it fails!
Thanks for noticing! ><

Copy link
Contributor

Choose a reason for hiding this comment

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

No worries haha actually I realized we've made this mistake in other areas also 😆 I'll make an issue to clean that up

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alright! 💯

src/app/core/services/repository.service.ts Outdated Show resolved Hide resolved
Copy link
Contributor

@anubh-v anubh-v left a comment

Choose a reason for hiding this comment

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

Thanks @seanlowjk for working on this.

I have a different opinion that the label synchronisation custom operator should reside in LabelService, and not the newly created RepositoryService.

It seems neater to keep label-related responsibilities under LabelService.
The RepositoryService can be in charge of checking whether a repo exists, asking the user for permission to create a repo, and creating the repo (using GithubService under-the-hood as you mentioned).

We can rename RepositoryService --> RepoCreatorService (other naming suggestions welcome)

What do you all think?

src/app/core/services/repository.service.ts Outdated Show resolved Hide resolved
@seanlowjk
Copy link
Contributor Author

Yea since it is mainly responsible for the creating of the repository due to the steps mentioned earlier, it would be better to use the name of RepoCreatorService!

I will shift synclabels() to the LabelService and the checking of sessionCreation in PhaseService as two separate steps!

@seanlowjk
Copy link
Contributor Author

I am not sure if what I did for custom operator captures the original idea that was suggested! Would like your advice on this >< @ptvrajsk @anubh-v

src/app/core/services/phase.service.ts Outdated Show resolved Hide resolved
src/app/core/services/phase.service.ts Outdated Show resolved Hide resolved
src/app/core/services/repo-creator.service.ts Outdated Show resolved Hide resolved
@seanlowjk seanlowjk changed the title Create RepositoryService and add Implementation and Tests for syncLabels() Move Implementation and Tests for syncLabels() Feb 20, 2021
@seanlowjk
Copy link
Contributor Author

Updated the title of the PR and the description to better suit the purpose of this PR!

src/app/core/services/label.service.ts Outdated Show resolved Hide resolved
tests/services/phase.service.spec.ts Outdated Show resolved Hide resolved
src/app/core/services/label.service.ts Outdated Show resolved Hide resolved
tests/services/label.service.spec.ts Outdated Show resolved Hide resolved
@anubh-v anubh-v changed the title Move Implementation and Tests for syncLabels() LabelService: create custom operator for label synchronisation Feb 22, 2021
@anubh-v
Copy link
Contributor

anubh-v commented Feb 22, 2021

@seanlowjk I've edited your PR title to make it easier to understand. Let's try to use the scope: change style for titles, as it helps readers quickly understand which part of the app is being modified. (i.e. LabelService: create custom ...)
This is consistent with our guidelines for commit message titles too.

@seanlowjk
Copy link
Contributor Author

@anubh-v have made the following changes! I have tested the following !

1, Tests that 15 labels to be created when fetchAllLabels returns []
2. Tests that < 15 labels to be created when fetchAllLabels return at least 1 label
3. Tests that 0 labels to be created when fetchAllLabels returns all the required labels!

Abstracted the asseting of label creation via assertLabelCreated and assertLabelNotCreated

Hope this helps in testing of the cases as mentioned earlier!

Copy link
Contributor

@anubh-v anubh-v left a comment

Choose a reason for hiding this comment

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

Looks good 👍 , just one nit

tests/services/label.service.spec.ts Outdated Show resolved Hide resolved
@anubh-v
Copy link
Contributor

anubh-v commented Feb 24, 2021

@seanlowjk thanks for the work. Can you write up the commit message for this PR?

@seanlowjk
Copy link
Contributor Author

@anubh-v I have key-ed in the suggested commit message to capture the idea of this PR! Hope this commit message is better with regards to capturing the purpose and how we can solve the issue mentioned!

@anubh-v anubh-v merged commit 517b037 into CATcher-org:master Feb 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants