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

Fix Spec has no expectations errors #2371

Conversation

alexandrevryghem
Copy link
Member

@alexandrevryghem alexandrevryghem commented Jul 16, 2023

Description

Currently there are some tests (in total 60) who don't have any expecations, this is often because of Observables who only emit after the test has already finished. In this PR I enabled a rule to always throw Spec has no expectations for tests without expectations, this PR also fixes those tests. Some tests also don't expect anything because they only exist to check if an error is thrown, for those tests I added expect.nothing() at the end to make sure they also succeed with this rule (I also always added some inline explanation on the places where I used this). Enabling this rule would mean that small errors like this one would be catched earlier, instead of making you think that everything is working.

Instructions for Reviewers

I committed every test I fixed seperatly with a short explanation with the reason of the change in the commit description, I think this will make it easier to review 🤷.

Checklist

  • My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
  • My PR passes ESLint validation using yarn lint
  • My PR doesn't introduce circular dependencies (verified via yarn check-circ-deps)
  • My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
  • My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
  • If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
  • If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
  • If my PR fixes an issue ticket, I've linked them together.

Added a expect().nothing() to the test who don't expect anything but just ensure that no error is thrown
- Wrong css class was used
- The check to see if the offset was defined did not exist
Reverted the way you detect when an item is selected by using observables again instead of promises. The reason why it didn't work without the old observable approach was because `VocabularyTreeviewModalComponent` didn't have a `select` `@Output` like `VocabularyTreeviewComponent`
- renamed `showBackButton` to `showBackButton$` because it's an observable
- `showBackButton$` only emits `true` when the back button should be shown, it does not emit `false` when it should be hidden, it just did nothing
- The buttons are now not disabled anymore but hidden when you don't have the correct authorization
- Wrong css class was used for the edit buttons
- Wrong css class was used
- The check to see if the offset was defined did not exist
The fixture.whenStable() was not awaited
- The isWithdrawn was set twice to mockItem1
- The expected observable was not correctly compared
The test's searchData & the searchData from the SubscriptionsDataService were not linked
- The store dispatch was not called through so the store was never updated
- To initialize the store using provideMockStore I rewrote the test to work through injection
Because of the switch from BehaviourSubject to Subject the tests always failed because of a timout because the previous state is not kept with Subject and should be manually triggered during the tests
…ponent, CommunityPageSubCommunityListComponent no expectation tests

Because their child components use a themed component the changes need to be detected twice, this is a side effect from the component being created dynamically
- Because the custom theme is disabled by default I replaced it with the dspace theme who is still enabled by default
- Because the child components use a themed component the changes need to be detected twice, this is a side effect from the component being created dynamically
- Removed duplicate request
- Added expect().nothing() because httpMock.expectNone will throw an error when a request is made
@alexandrevryghem alexandrevryghem self-assigned this Jul 16, 2023
@alexandrevryghem alexandrevryghem added the testing framework Related specifically to Unit or Integration (e2e) Tests label Jul 16, 2023
@alexandrevryghem alexandrevryghem added this to the 8.0 milestone Jul 16, 2023
@alexandrevryghem
Copy link
Member Author

There are still 2 tests failing, in my opinion they can be removed, but I would prefer having someone else's feedback before deleting them:

  • For the failing test in Notifications reducer, the test ChangeDetectorRef part needs to be removed and then you can see that the test fails. The problem is that tick() & flush() don't work well with ngrx, this means that you can't use those to increment the time, I tried using delay(), but while fixing the tests from ObjectUpdatesEffects, the only way I found to correctly wait that the actions where handled there was to add expect(updatesEffects.mapLastActions$).toBeObservable(cold()). I tried reusing this approach here but it didn't work, the failing test also doesn't actually test code from the NotificationsReducer, but rather code from ObjectUpdatesEffects.removeAfterDiscardOrReinstateOnUndo$, because this timeout code has already been tested I thought that maybe it could be removed
  • For the failing test in ExternalSourceService, it's normal that this test fails, it's because of this code. The code prevents that stale objects from the cache are returned, this way a backend request can be made, and it will update the store. That value can't be returned from the backend in the tests because there is no backend, so this test can't be fixed. The only thing you could do is put the correct value in the store and check that the correct value is in the store but this is pointless. There is already a test who checks that the backend request is made here, so in my opinion this test can be removed.

@tdonohue tdonohue added the 1 APPROVAL pull request only requires a single approval to merge label Jul 17, 2023
@github-actions
Copy link

Hi @alexandrevryghem,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

@tdonohue tdonohue self-requested a review December 14, 2023 15:56
…xpectations_contribute-main

# Conflicts:
#	src/app/shared/browse-by/shared-browse-by.module.ts
Buttons to which you don't have access are now hidden by default instead of disabled
Copy link

Hi @alexandrevryghem,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

Copy link

Hi @alexandrevryghem,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

…xpectations_contribute-main

# Conflicts:
#	src/app/shared/search/search-filters/search-filter/search-hierarchy-filter/search-hierarchy-filter.component.ts
@alexandrevryghem alexandrevryghem force-pushed the fix-specs-without-expectations_contribute-main branch from db710c5 to 109418b Compare February 29, 2024 18:55
@tdonohue
Copy link
Member

@alexandrevryghem : I finally got around to reading this PR and your comments above about the failing tests. I agree with your logic that it seems reasonable to remove both of the failing tests.

So, if you find time to update this to delete the failing tests & get this passing tests...then I'll do my best to move this forward soon as it seems like a very useful change before we start doing major code updates (to Angular 16, etc)

@alexandrevryghem
Copy link
Member Author

@tdonohue: All tests are fixed now

Copy link
Member

@tdonohue tdonohue left a comment

Choose a reason for hiding this comment

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

👍 Thanks @alexandrevryghem for this necessary improvement/fix! I looked over the code and it looks good. Also verified locally that all tests on existing main pass this check.

@tdonohue tdonohue merged commit 4cc5a38 into DSpace:main Mar 4, 2024
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 APPROVAL pull request only requires a single approval to merge code task testing framework Related specifically to Unit or Integration (e2e) Tests
Projects
No open projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

2 participants