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

Development: Remove deprecated router module in client tests #9439

Merged
merged 6 commits into from
Oct 8, 2024

Conversation

JohannesWt
Copy link
Contributor

@JohannesWt JohannesWt commented Oct 8, 2024

Checklist

General

Client

Motivation and Context

Currently a lot of client tests use the RouterTestingModule which is deprecated.

Description

This PR replaces the RouterTestingModule with provideRouter() or RouterModule.forRoot() according to Angular Documentation

Steps for Testing

All client tests must pass

Testserver States

Note

These badges show the state of the test servers.
Green = Currently available, Red = Currently locked
Click on the badges to get to the test servers.







Review Progress

Code Review

  • Code Review 1
  • Code Review 2

Test Coverage

unchanged

Summary by CodeRabbit

  • Refactor
    • Updated test setups across multiple components to replace RouterTestingModule with RouterModule.forRoot() or provideRouter, enhancing routing configuration in tests.
    • Streamlined import statements for improved clarity and maintainability.
  • Chores
    • Consolidated imports and updated providers in various test files to reflect the new routing setup.

@JohannesWt JohannesWt self-assigned this Oct 8, 2024
@github-actions github-actions bot added the tests label Oct 8, 2024
@JohannesWt JohannesWt marked this pull request as ready for review October 8, 2024 09:13
@JohannesWt JohannesWt requested a review from a team as a code owner October 8, 2024 09:13
Copy link

coderabbitai bot commented Oct 8, 2024

Walkthrough

The changes in this pull request involve updating the test setups for various components by replacing the RouterTestingModule with RouterModule or provideRouter. This transition indicates a shift towards utilizing the standard Angular router setup for testing, enhancing the routing configuration within the test environment. The overall structure of the test cases remains unchanged, ensuring that the components' functionalities continue to be validated effectively.

Changes

File Path Change Summary
src/test/javascript/spec/component/assessment-dashboard/... Updated import from RouterTestingModule to RouterModule.forRoot([]).
src/test/javascript/spec/component/assessment-shared/... Replaced RouterTestingModule with RouterModule.forRoot([]) in imports.
src/test/javascript/spec/component/competencies/... Removed RouterTestingModule, added provideRouter in the test setup.
src/test/javascript/spec/component/complaints/... Updated to use provideRouter([]) instead of RouterTestingModule.
src/test/javascript/spec/component/course/... Replaced RouterTestingModule with RouterModule.forRoot([]) across multiple tests.
src/test/javascript/spec/component/file-upload-assessment/... Changed from RouterTestingModule to RouterModule.forRoot([]) in imports.
src/test/javascript/spec/component/footer/... Updated to use RouterModule.forRoot([]) instead of RouterTestingModule.
src/test/javascript/spec/component/tutorial-groups/... Removed RouterTestingModule, added RouterModule.forRoot([]) in imports.

Suggested labels

client, small, bugfix

Suggested reviewers

  • JohannesStoehr
  • SimonEntholzer
  • pzdr7
  • krusche

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai or @coderabbitai title anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 46

🧹 Outside diff range comments (35)
src/test/javascript/spec/component/tutorial-groups/shared/tutorial-group-row.component.spec.ts (1)

Line range hint 42-45: Enhance test case with more specific expectations.

While the current test case checks if the component is created, it could be more specific and comprehensive. Consider adding more detailed assertions to validate the component's properties and behavior.

Here's an example of how you could enhance the test case:

it('should create and initialize correctly', () => {
    expect(component).toBeTruthy();
    expect(component.tutorialGroup).toEqual(tutorialGroup);
    expect(component.showIdColumn).toBeTrue();
    // Add more specific expectations based on the component's properties and behavior
});

This approach aligns with the guideline for expectation specificity and provides a more robust test case.

src/test/javascript/spec/component/tutorial-groups/course-tutorial-groups/course-tutorial-group-card.component.spec.ts (1)

Line range hint 1-48: Overall implementation successfully replaces RouterTestingModule.

The changes in this file effectively replace the deprecated RouterTestingModule with RouterModule, aligning with the PR objectives and Angular's best practices. However, there are a few additional improvements that could be made:

  1. Consider using NgMocks for mocking components and directives, as per the coding guidelines:
import { MockComponent, MockDirective } from 'ng-mocks';

// In the TestBed configuration
declarations: [
  CourseTutorialGroupCardComponent,
  MockComponent(FaIconComponent),
  MockDirective(TranslateDirective),
  // ... other declarations
],
  1. Use more specific expectations in your tests, as suggested in the coding guidelines. For example:
it('should create', () => {
  expect(component).toBeTruthy();
});

Could be improved to:

it('should create', () => {
  expect(component).toBeInstanceOf(CourseTutorialGroupCardComponent);
});
  1. Consider mocking irrelevant dependencies to improve test performance and isolation.

These suggestions will help improve the overall quality and performance of your test suite.

src/test/javascript/spec/component/shared/main.component.spec.ts (1)

Line range hint 1-71: LGTM: Overall test structure and implementation

The test suite for JhiMainComponent is well-structured and follows the coding guidelines:

  • Jest is used as the testing framework.
  • Mock services and components are correctly provided.
  • Test cases use recommended assertion methods (toBeNull, not.toBeNull).
  • The tests cover the component's behavior regarding footer visibility based on exam state.

Consider grouping related tests using describe blocks for better organization:

describe('Footer visibility', () => {
  it('should display footer if there is no exam', () => {
    // ... existing test code ...
  });

  it('should not display footer during an exam', () => {
    // ... existing test code ...
  });
});

This approach improves test readability and makes it easier to add related tests in the future.

src/test/javascript/spec/component/grading-system/grading-system.component.spec.ts (1)

Line range hint 1-78: Consider adding a test for router configuration.

The changes introduce a router configuration in the TestBed setup. To ensure this configuration is correctly applied, consider adding a test that verifies the router's presence and configuration.

Here's a suggested test to add:

it('should have an empty router configuration', () => {
  const router = TestBed.inject(Router);
  expect(router.config.length).toBe(0);
});

This test will verify that the router is properly injected and configured with an empty routes array.

src/test/javascript/spec/component/team/teams.component.spec.ts (1)

Line range hint 71-85: Consider adding routing-specific tests

While the existing test case for loading teams remains unchanged and valid, consider adding new test cases to specifically cover routing scenarios. This would ensure that the component behaves correctly with the new routing setup.

Here's an example of a test you might add:

it('should navigate to correct route when team is selected', fakeAsync(() => {
  const navigateSpy = spyOn(router, 'navigate');
  comp.ngOnInit();
  tick();
  
  comp.onRowSelect({ selected: [mockTeams[0]] });
  tick();

  expect(navigateSpy).toHaveBeenCalledWith(['/team', mockTeams[0].id]);
}));

This test would verify that the component correctly navigates to a team's detail page when a team is selected, assuming such functionality exists in the component.

src/test/javascript/spec/component/exam/participate/general-information/exam-general-information.component.spec.ts (1)

Line range hint 1-146: Consider improving test isolation and setup.

While the tests are well-organized and cover various scenarios, consider the following improvements:

  1. Use beforeEach to reset exam and studentExam objects instead of reassigning them. This ensures each test starts with a clean state.

  2. Consider using jest.spyOn for mocking methods instead of full component mocks where applicable.

  3. Use more specific expectations. For example, replace expect(fixture).toBeDefined() with more meaningful assertions about the component's state or behavior.

Here's an example of how you could improve the beforeEach setup:

describe('ExamGeneralInformationComponent', () => {
    let exam: Exam;
    let studentExam: StudentExam;

    beforeEach(() => {
        const startDate = dayjs('2022-02-06 02:00:00');
        const endDate = dayjs(startDate).add(1, 'hours');
        
        exam = { id: 1, title: 'ExamForTesting', startDate, endDate, testExam: false } as Exam;
        studentExam = { id: 1, exam, user: { id: 1, name: 'Test User' } as User, workingTime: 60, submitted: true } as StudentExam;

        return TestBed.configureTestingModule({
            // ... (rest of the setup)
        })
        .compileComponents()
        .then(() => {
            fixture = TestBed.createComponent(ExamGeneralInformationComponent);
            component = fixture.componentInstance;
        });
    });

    // ... (rest of the tests)
}

This setup ensures each test starts with fresh exam and studentExam objects, improving test isolation.

src/test/javascript/spec/service/user-route-access.service.spec.ts (1)

Line range hint 42-48: Approved: TestBed configuration updated, but consider using provideRouter().

The replacement of RouterTestingModule with RouterModule.forRoot() aligns with the PR objectives and provides a more realistic routing setup for tests. However, consider using provideRouter() for a more lightweight approach in the test environment:

import { provideRouter } from '@angular/router';

// In the TestBed configuration
providers: [
  provideRouter([
    {
      path: route,
      component: CourseExerciseDetailsComponent,
    },
  ]),
  // ... other providers
],

This approach avoids setting up the full routing infrastructure in the test environment while still providing the necessary routing configuration.

src/test/javascript/spec/component/exam/participate/exam-start-information/exam-start-information.component.spec.ts (1)

Line range hint 43-53: LGTM: TestBed configuration updated to use provideRouter.

The replacement of RouterTestingModule with provideRouter([]) in the TestBed configuration is correct and aligns with the PR objective. This change follows Angular's latest best practices for testing.

Consider moving the providers array to a separate line for better readability:

imports: [ArtemisSharedModule, ArtemisSharedComponentModule, ArtemisExamSharedModule],
declarations: [
    // ... (unchanged)
],
providers: [
    provideRouter([])
],
src/test/javascript/spec/component/exam/exam-scores/exam-scores-average-scores-graph.component.spec.ts (2)

Line range hint 86-90: Consider using more specific Jest matchers.

While the test cases generally follow the coding guidelines, there's room for improvement in the use of Jest matchers. Consider using more specific matchers as per the coding guidelines:

  1. Replace expect(navigateToExerciseMock).toHaveBeenCalledOnce(); with expect(navigateToExerciseMock).toHaveBeenCalledTimes(1);
  2. For boolean checks, use toBeTrue() or toBeFalse() instead of toBe(true) or toBe(false).
  3. For checking if a function was not called, use expect(navigateToExerciseMock).not.toHaveBeenCalled(); as you've correctly done.

Here's an example of how you could refactor one of the test cases:

it('should navigate if event is valid', () => {
    component.lookup['test'] = { exerciseId: 42, exerciseType: ExerciseType.QUIZ };

    component.onSelect(event);

    expect(navigateToExerciseMock).toHaveBeenCalledTimes(1);
    expect(navigateToExerciseMock).toHaveBeenCalledWith(42, ExerciseType.QUIZ);
});

Also applies to: 124-128, 134-138


Line range hint 140-153: Consider mocking LocaleConversionService more effectively.

The current setup for LocaleConversionService might not be optimal. Instead of mocking the entire service, consider mocking only the required method:

MockProvider(LocaleConversionService, {
    toLocaleString: jest.fn().mockImplementation((score: number) => score.toString()),
}),

This approach allows for easier spying and verification of the toLocaleString method calls if needed in future tests.

src/test/javascript/spec/component/course/course-exercises.component.spec.ts (1)

Line range hint 1-156: Compliance with coding guidelines: Mostly adherent, with room for improvement.

The test file generally adheres to the specified coding guidelines:

  • Jest is used for testing.
  • NgMocks is utilized for mocking components and directives.
  • Full module imports are avoided.
  • Irrelevant dependencies are mocked appropriately.
  • NO_ERRORS_SCHEMA is not used.

To improve expectation specificity, consider updating the following test:

it('should initialize', () => {
  expect(component.course).toEqual(course);
  expect(courseStorageStub.mock.calls).toHaveLength(1);
  expect(courseStorageStub.mock.calls[0][0]).toBe(course.id);
  component.ngOnDestroy();
});

You can make the expectations more specific:

it('should initialize', () => {
  expect(component.course).toEqual(expect.objectContaining({ id: course.id }));
  expect(courseStorageStub).toHaveBeenCalledTimes(1);
  expect(courseStorageStub).toHaveBeenCalledWith(course.id);
  component.ngOnDestroy();
});

This change improves the test's readability and makes it more robust against future changes in the Course object structure.

src/test/javascript/spec/component/file-upload-exercise/file-upload-exercise-detail.component.spec.ts (1)

Incomplete routing tests detected

It appears that routing-related tests are not present in the current test file or in related test files. Please ensure that routing functionality is adequately tested to maintain comprehensive test coverage.

🔗 Analysis chain

Line range hint 1-180: Verify completeness of routing tests

While the changes to replace RouterTestingModule with provideRouter are correct, it's important to ensure that all routing functionality is still adequately tested. Since no changes were made to the actual test cases in this file, please verify that:

  1. The routing functionality for this component is tested elsewhere if needed.
  2. There are no routing-specific tests that need to be added or updated in this file.

This will help maintain the overall test coverage and ensure that the routing behavior is still correctly validated.

To assist in this verification, you can run the following script to check for any routing-related tests:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for routing-related tests in the component and its related files

# Search for routing-related tests in the current file
echo "Checking for routing tests in the current file:"
rg --type typescript "route|navigate|params" src/test/javascript/spec/component/file-upload-exercise/file-upload-exercise-detail.component.spec.ts

# Search for related routing test files
echo "Checking for related routing test files:"
fd -e ts -p "route.*spec" src/test/javascript/spec/component/file-upload-exercise/

Length of output: 464


Script:

#!/bin/bash
# Description: Check for routing-related tests in the component and its related files

# Search for routing-related tests in the current file using a correct TypeScript file pattern
echo "Checking for routing tests in the current file:"
rg "route|navigate|params" src/test/javascript/spec/component/file-upload-exercise/file-upload-exercise-detail.component.spec.ts

# Search for related routing test files using a glob pattern for TypeScript files
echo "Checking for related routing test files:"
fd -e ts "route.*spec.ts" src/test/javascript/spec/component/file-upload-exercise/

Length of output: 806

src/test/javascript/spec/component/shared/sidebar/conversation-options.component.spec.ts (2)

Line range hint 54-65: LGTM: TestBed configuration updated correctly with provideRouter.

The replacement of RouterTestingModule with provideRouter is implemented correctly. The route configuration matches the previous setup, ensuring consistency. The use of mocks (MockComponent, MockDirective, MockPipe) is maintained, adhering to the mocking guidelines.

One minor suggestion for improvement:

Consider extracting the route configuration into a separate constant for better readability and easier maintenance. For example:

const testRoutes = [
  { path: 'courses/:courseId/lectures/:lectureId', component: CourseLectureDetailsComponent },
  { path: 'courses/:courseId/exercises/:exerciseId', component: CourseExerciseDetailsComponent },
  { path: 'courses/:courseId/exams/:examId', component: ExamDetailComponent },
];

// Then in the providers array:
providers: [
  provideRouter(testRoutes),
  // ... other providers
]

This change would improve code organization and make it easier to update routes in the future if needed.


Line range hint 84-145: LGTM: Test cases remain valid and follow best practices.

The test cases are unaffected by the router configuration changes and continue to cover important scenarios such as updating favorites, hiding, muting, and opening dialogs. The use of fakeAsync and tick for handling asynchronous operations is appropriate.

One minor suggestion for improvement:

For consistency with the coding guidelines, consider updating the expectation for spy calls to use the recommended syntax. For example:

expect(updateIsFavoriteSpy).toHaveBeenCalledExactlyOnceWith(course.id, component.conversation.id, true);

This change would align with the guideline for spy call expectations: toHaveBeenCalledExactlyOnceWith.

Additionally, great job on maintaining high test coverage and following best practices for Angular testing!

src/test/javascript/spec/component/exam/manage/exams/exam-checklist-exercisegroup-table.component.spec.ts (2)

Line range hint 61-85: LGTM: TestBed configuration updated correctly.

The TestBed configuration has been successfully updated to use provideRouter instead of RouterTestingModule. The router configuration is comprehensive and covers all necessary routes for testing.

Consider moving the provideHttpClient() and provideHttpClientTesting() providers to the top of the providers array for better readability and consistency with Angular's recommended ordering of providers.

 providers: [
+    provideHttpClient(),
+    provideHttpClientTesting(),
     provideRouter([
         { path: 'course-management/:courseId/exams/:examId/edit', component: DummyComponent },
         { path: 'course-management/:courseId/exams/:examId/exercise-groups', component: DummyComponent },
         { path: 'course-management/:courseId/exams/:examId/assessment-dashboard', component: DummyComponent },
         { path: 'course-management/:courseId/exams/:examId/scores', component: DummyComponent },
         { path: 'course-management/:courseId/exams/:examId/student-exams', component: DummyComponent },
         { path: 'course-management/:courseId/exams/:examId/test-runs', component: DummyComponent },
         { path: 'course-management/:courseId/exams/:examId/students', component: DummyComponent },
     ]),
-    provideHttpClient(),
-    provideHttpClientTesting(),
 ],

Add Router-Related Tests to Ensure Comprehensive Coverage

The test file imports routing functionalities but does not include tests for router-related behavior. To ensure that navigation and route handling are properly tested, consider adding the following:

  • Tests for component navigation using the router.
  • Verification of route parameter handling within the component.
🔗 Analysis chain

Line range hint 93-153: Verify: Existing tests remain valid, consider adding router-related tests.

The existing test cases appear to be unaffected by the TestBed configuration changes. They still effectively test the onChanges lifecycle hook and its impact on component properties.

To ensure that the router configuration is working as expected with the new setup, consider adding tests that verify router-related functionality. This could include testing navigation or route parameter handling within the component.

Here's a script to verify if there are any existing router-related tests:

If no results are found, it would be beneficial to add tests that cover router interactions to ensure the new configuration is working as expected.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for existing router-related tests in the component spec file

# Test: Search for router-related test cases
rg --type typescript -i '(router|navigation|route).*it\(' src/test/javascript/spec/component/exam/manage/exams/exam-checklist-exercisegroup-table.component.spec.ts

echo "If no results are shown, consider adding router-related tests to cover the new configuration."

Length of output: 397


Script:

#!/bin/bash
# Description: Check for existing router-related tests in the component spec file

# Test: Search for router-related test cases without specifying file type
rg -i '(router|navigation|route).*it\(' src/test/javascript/spec/component/exam/manage/exams/exam-checklist-exercisegroup-table.component.spec.ts

echo "If no results are shown, consider adding router-related tests to cover the new configuration."

Length of output: 344


Script:

#!/bin/bash
# Description: Check for router-related imports and usage in the component spec file

# Test 1: Search for Angular Router imports
rg -i 'from.*@angular/router' src/test/javascript/spec/component/exam/manage/exams/exam-checklist-exercisegroup-table.component.spec.ts

# Test 2: Search for RouterTestingModule or ActivatedRoute usage in test cases
rg -i '(RouterTestingModule|ActivatedRoute)' src/test/javascript/spec/component/exam/manage/exams/exam-checklist-exercisegroup-table.component.spec.ts

echo "If no router-related imports or usage are found, consider adding router-related tests to cover the new configuration."

Length of output: 584

src/test/javascript/spec/component/course/course-management.component.spec.ts (1)

Line range hint 93-107: LGTM: Correct replacement of RouterTestingModule with provideRouter.

The change from RouterTestingModule to provideRouter([]) in the TestBed configuration is correct and aligns with Angular's latest best practices for testing components with routing dependencies.

Consider adding a comment explaining why an empty array is passed to provideRouter. This can help other developers understand the testing setup:

providers: [
  provideRouter([]), // Empty array as no specific routes are needed for this test
  // ... other providers
],
src/test/javascript/spec/integration/guided-tour/guided-tour.integration.spec.ts (1)

Line range hint 1-224: Overall changes look good, but consider adding a test for routing behavior.

The changes to replace RouterTestingModule with RouterModule.forRoot() are minimal and focused. They align well with the PR objectives and should provide a more realistic routing setup for the tests.

However, since we've changed the routing configuration, it might be beneficial to add a test case that specifically verifies the routing behavior. This would ensure that the new configuration works as expected in the context of the guided tour.

Consider adding a test case like this:

it('should navigate to the courses route', fakeAsync(() => {
  const router = TestBed.inject(Router);
  router.navigate(['/courses']);
  tick();
  expect(router.url).toBe('/courses');
}));

This will help verify that the new routing configuration is working correctly within the test environment.

src/test/javascript/spec/component/exam/manage/exam-students.component.spec.ts (1)

Line range hint 1-248: Consider enhancing router-related test coverage.

While the changes successfully replace the deprecated RouterTestingModule with provideRouter, there's an opportunity to improve the test suite:

  1. Consider adding specific router-related tests to ensure the component interacts correctly with the router after this change.
  2. Verify that all existing tests still pass with the new router configuration.
  3. If applicable, add tests for any router-dependent functionality in the component.

These additions would help ensure that the router configuration change doesn't introduce any unintended side effects.

src/test/javascript/spec/component/exam/participate/exercises/quiz-exam-submission.component.spec.ts (1)

Line range hint 50-59: LGTM: TestBed configuration updated correctly with provideRouter.

The replacement of RouterTestingModule.withRoutes([]) with provideRouter([]) in the TestBed configuration aligns with the PR objective and follows Angular's latest best practices. This change simplifies the test setup while maintaining the integrity of the test environment.

For consistency, consider moving provideRouter([]) to the beginning of the providers array:

providers: [provideRouter([]), MockProvider(ArtemisQuizService)],

This minor adjustment improves readability by grouping router-related configurations together.

src/test/javascript/spec/component/overview/course-exams/course-exams.component.spec.ts (1)

Add routing-related tests to ensure routing functionality is properly verified.

While MockRouter is used, there are no tests or assertions related to routing behavior. It's important to verify that routing-related functionality is properly tested to maintain application reliability. Please consider adding test cases that cover routing behavior and related assertions.

🔗 Analysis chain

Line range hint 1-324: Verify routing-related functionality in tests.

While the changes to the router configuration are correct, it's important to ensure that all routing-related functionality is still properly tested. Please verify that:

  1. Any tests that rely on router behavior are still functioning correctly.
  2. The MockRouter is still being used appropriately where needed.
  3. Any route-related assertions in the tests are still valid with the new configuration.

To help with this verification, you can run the following script to check for any router-related test cases:

This script will help identify any router-related tests or assertions that might need additional attention due to the configuration change.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for router-related test cases and assertions

# Search for router-related test descriptions
echo "Router-related test cases:"
rg --type typescript "it\(.*router.*" src/test/javascript/spec/component/overview/course-exams/course-exams.component.spec.ts

# Search for router-related assertions
echo "\nRouter-related assertions:"
rg --type typescript "expect.*router.*" src/test/javascript/spec/component/overview/course-exams/course-exams.component.spec.ts

# Search for MockRouter usage
echo "\nMockRouter usage:"
rg --type typescript "MockRouter" src/test/javascript/spec/component/overview/course-exams/course-exams.component.spec.ts

Length of output: 663


Script:

#!/bin/bash
# Description: Check for router-related test cases and assertions by targeting .ts files

# Search for router-related test descriptions
echo "Router-related test cases:"
rg "it\(.*router.*" --glob "*.ts" src/test/javascript/spec/component/overview/course-exams/course-exams.component.spec.ts

# Search for router-related assertions
echo "\nRouter-related assertions:"
rg "expect.*router.*" --glob "*.ts" src/test/javascript/spec/component/overview/course-exams/course-exams.component.spec.ts

# Search for MockRouter usage
echo "\nMockRouter usage:"
rg "MockRouter" --glob "*.ts" src/test/javascript/spec/component/overview/course-exams/course-exams.component.spec.ts

Length of output: 648

src/test/javascript/spec/component/text-editor/text-editor.component.spec.ts (1)

Line range hint 68-86: Consider using NgMocks for more effective component mocking.

While the current mocking approach using MockComponent and MockDirective is functional, consider using NgMocks for a more robust and maintainable mocking strategy. NgMocks provides a powerful set of tools for mocking Angular components, directives, and pipes.

Here's an example of how you could refactor this using NgMocks:

import { MockComponent, MockDirective, MockPipe } from 'ng-mocks';

// In the declarations array
declarations: [
  TextEditorComponent,
  MockComponent(SubmissionResultStatusComponent),
  MockComponent(ButtonComponent),
  // ... other components
  MockPipe(HtmlForMarkdownPipe),
  MockPipe(ArtemisTranslatePipe),
  MockDirective(NgModel),
  MockDirective(TranslateDirective),
],

Using NgMocks can help improve the isolation of your unit tests and make them less brittle to changes in the mocked components.

src/test/javascript/spec/component/exam/manage/exams/exam-detail.component.spec.ts (1)

Line range hint 64-77: LGTM: Routing configuration updated correctly with a suggestion.

The RouterTestingModule has been successfully replaced with RouterModule.forRoot(), which aligns with the PR objective. The new configuration provides a more comprehensive routing setup for testing, covering various exam-related functionalities.

Consider extracting the route configuration into a separate constant for better readability and maintainability. For example:

const testRoutes = [
  { path: 'course-management/:courseId/exams/:examId/edit', component: DummyComponent },
  { path: 'course-management/:courseId/exams/:examId/exercise-groups', component: DummyComponent },
  // ... other routes
];

// Then in the imports array:
RouterModule.forRoot(testRoutes),

This approach would make it easier to manage and update the test routes in the future.

src/test/javascript/spec/component/exam/participate/summary/result-overview/exam-result-overview.component.spec.ts (1)

Line range hint 1-359: Overall test quality is high, with a suggestion for improved organization.

The test suite for ExamResultOverviewComponent is comprehensive and well-structured. It covers various scenarios, including edge cases and error handling. The use of mocking utilities (MockModule, MockComponent, MockPipe, MockProvider) effectively isolates the component under test.

To further improve the test organization and readability, consider grouping related tests using nested describe blocks. For example:

describe('ExamResultOverviewComponent', () => {
  // ... setup code ...

  describe('Initialization', () => {
    it('should handle error correctly', () => { /* ... */ });
    it('should retrieve exam grade correctly', () => { /* ... */ });
    it('should initialize and calculate scores correctly', () => { /* ... */ });
  });

  describe('Score calculations', () => {
    it('should display 0 if no exercises are present', () => { /* ... */ });
    // ... other score-related tests ...
  });

  // ... other test groups ...
});

This organization can make it easier to locate and maintain specific tests as the test suite grows.

src/test/javascript/spec/component/exam/manage/student-exams/student-exam-detail.component.spec.ts (1)

Line range hint 1-380: Adherence to coding guidelines

The test file generally follows the provided coding guidelines:

  • Jest is used for testing.
  • NgMocks is utilized for mocking components and services.
  • Expectations use specific assertions as recommended.

Consider the following improvements to align more closely with the guidelines:

  1. Use toBeTrue() and toBeFalse() consistently instead of toBe(true) and toBe(false) for boolean assertions.
  2. For spy assertions, consider using toHaveBeenCalledExactlyOnceWith() instead of toHaveBeenCalledOnce() where applicable.
  3. Ensure that all irrelevant dependencies are mocked to improve test performance.
src/test/javascript/spec/component/shared/code-button.component.spec.ts (1)

Line range hint 94-105: LGTM: Correct setup of provideRouter

The removal of RouterTestingModule from imports and addition of provideRouter([]) to providers correctly updates the routing setup for tests. This change aligns with the PR objective and follows Angular's latest testing practices.

Consider adding a comment explaining why an empty array is passed to provideRouter. This can help future developers understand that no specific routes are needed for these tests.

 providers: [
+    // No specific routes needed for these tests
     provideRouter([]),
     MockProvider(AlertService),
     { provide: FeatureToggleService, useClass: MockFeatureToggleService },
src/test/javascript/spec/component/modeling-submission/modeling-submission.component.spec.ts (1)

Line range hint 1-577: LGTM! Consider adding a test for RouterModule configuration.

The test suite remains comprehensive and well-structured, covering various scenarios for the ModelingSubmissionComponent. The lack of changes to the test logic maintains the integrity of the test suite.

Consider adding a test case to verify that the RouterModule is correctly configured with the expected routes. This would ensure that the change from RouterTestingModule to RouterModule.forRoot doesn't introduce any routing-related issues. Here's a suggested test case:

it('should configure RouterModule with the correct routes', () => {
  const router = TestBed.inject(Router);
  expect(router.config).toEqual([routes[0]]);
});

This test would verify that the RouterModule is configured with the expected route from the routes array.

src/test/javascript/spec/component/overview/course-statistics/course-statistics.component.spec.ts (2)

Line range hint 331-342: LGTM: TestBed configuration updated correctly.

The TestBed configuration has been updated to use provideRouter([]) instead of RouterTestingModule. This change aligns with the latest Angular testing practices.

Consider moving the provideRouter([]) to the imports array instead of the providers array. While it works in both places, it's more conventional to include it in imports. Here's a suggested change:

 imports: [
   ArtemisTestModule,
   TreeviewModule.forRoot(),
   MockModule(PieChartModule),
   MockModule(BarChartModule),
   MockModule(NgbTooltipModule),
+  provideRouter([]),
 ],
 declarations: [
   // ... (unchanged)
 ],
 providers: [
-  provideRouter([]),
   MockProvider(ArtemisNavigationUtilService),
   MockProvider(ChartCategoryFilter),
   {
     provide: ActivatedRoute,
     useValue: { parent: { params: of(1) } },
   },
 ],

Line range hint 331-342: Consider adding a test for router integration.

The existing tests remain valid with the new router setup. However, to ensure complete coverage of the changes, consider adding a test that specifically verifies the router integration with the new provideRouter setup.

Here's a suggested additional test:

it('should correctly use the router', () => {
  const router = TestBed.inject(Router);
  const spy = jest.spyOn(router, 'navigate');
  
  // Trigger a navigation action in your component
  comp.someNavigationMethod();
  
  expect(spy).toHaveBeenCalledWith(['expected', 'route']);
});

This test will help ensure that the new router setup is working as expected within the component.

src/test/javascript/spec/component/exam/participate/summary/exam-result-summary.component.spec.ts (2)

Line range hint 175-202: Good job updating the test setup to use providers!

The changes in the sharedSetup function correctly implement the new provider-based approach:

  1. Removal of the imports array aligns with the shift away from module-based testing.
  2. Addition of provideRouter([]), provideHttpClient(), and provideHttpClientTesting() in the providers array ensures proper setup of routing and HTTP testing environments.

These changes make the test setup more flexible and easier to customize for specific test scenarios.

Consider grouping related providers together for better readability. For example:

providers: [
  provideRouter([]),
  provideHttpClient(),
  provideHttpClientTesting(),
  // ... other providers
]

Line range hint 1-585: Consider standardizing mocking and asynchronous testing approaches

Throughout the file, there's an inconsistent use of mocking techniques and asynchronous testing methods. To improve maintainability and readability, consider standardizing these approaches:

  1. Mocking: Currently, the file uses both jest.spyOn and MockProvider. Consider using MockProvider consistently for all service mocks, as it integrates well with Angular's dependency injection system.

  2. Asynchronous testing: Some tests use fakeAsync and tick(), while others don't. Evaluate each test case and use fakeAsync and tick() consistently for tests that involve asynchronous operations.

Example of standardized mocking:

providers: [
  // ... other providers
  MockProvider(ThemeService, {
    print: jest.fn().mockResolvedValue(undefined),
  }),
  MockProvider(ExamParticipationService, {
    loadStudentExamGradeInfoForSummary: jest.fn().mockReturnValue(of({ ...gradeInfo })),
  }),
  // ... other mocked services
]

Standardizing these approaches will make the test suite more consistent and easier to maintain.

src/test/javascript/spec/component/text-submission-assessment/text-submission-assessment.component.spec.ts (1)

Line range hint 437-453: Tests appear unaffected by router changes

The switch from RouterTestingModule to provideRouter doesn't seem to have negatively impacted any existing tests. The 'should go to next submission' test, which uses router.navigate, should continue to function correctly with the new setup.

To further improve the robustness of your tests, consider adding a specific test for router navigation using fakeAsync and tick(). This can help ensure that the router changes haven't introduced any subtle issues:

it('should navigate correctly', fakeAsync(() => {
  const navigateSpy = jest.spyOn(router, 'navigate');
  component.navigateToSomeRoute();
  tick();
  expect(navigateSpy).toHaveBeenCalledWith(['/expected-route']);
}));

This addition would provide more comprehensive coverage of the router functionality within your component.

src/test/javascript/spec/component/exam/exam-update.component.spec.ts (2)

Line range hint 76-94: LGTM: Updated test setup for modern Angular testing

The changes to the TestBed configuration are good updates, transitioning from the module-based approach to the provider-based approach. This aligns with modern Angular testing best practices and should make the tests more focused and easier to maintain.

Consider grouping related providers together for better readability. For example:

 providers: [
+    provideHttpClient(),
+    provideHttpClientTesting(),
+    provideRouter(routes),
     { provide: LocalStorageService, useClass: MockSyncStorage },
     { provide: SessionStorageService, useClass: MockSyncStorage },
     MockDirective(TranslateDirective),
     {
         provide: ActivatedRoute,
         useValue: {
             data: of({ exam: examWithoutExercises, course }),
             params: of({ courseId: '1' }),
             url: of([{ path: '' }] as UrlSegment[]),
         },
     },
     MockProvider(AlertService),
     MockProvider(GradingSystemService, {
         // ... (rest of the code)
     }),
-    provideHttpClient(),
-    provideHttpClientTesting(),
-    provideRouter(routes),
 ],

Line range hint 607-629: LGTM: Consistent update of test setup for import exams

The changes to the TestBed configuration in the "import exams" describe block are consistent with the earlier updates, which is good for maintaining a uniform testing strategy across the file.

As suggested earlier, consider grouping related providers together for better readability:

 providers: [
+    provideHttpClient(),
+    provideHttpClientTesting(),
+    provideRouter(routes),
     { provide: LocalStorageService, useClass: MockSyncStorage },
     { provide: SessionStorageService, useClass: MockSyncStorage },
     MockDirective(TranslateDirective),
     {
         provide: ActivatedRoute,
         useValue: {
             data: of({ exam: examForImport, course }),
             params: of({ examId: '3', courseId: '1' }),
             url: of([{ path: 'import' }] as UrlSegment[]),
         },
     },
     MockProvider(AlertService),
     MockProvider(GradingSystemService, {
         // ... (rest of the code)
     }),
-    provideHttpClient(),
-    provideHttpClientTesting(),
-    provideRouter(routes),
 ],
src/test/javascript/spec/component/programming-assessment/code-editor-tutor-assessment-container.component.spec.ts (1)

Line range hint 1-1000: Summary of routing configuration update and its implications.

The changes made to this test file represent a shift from using RouterTestingModule to provideRouter([]) for handling routing in the test environment. This update aligns with modern Angular testing practices and should offer more flexibility in configuring routes for tests.

Key points:

  1. The import statements have been updated to remove RouterTestingModule and add provideRouter.
  2. The TestBed configuration now uses provideRouter([]) instead of including RouterTestingModule in the imports.
  3. Individual test cases remain largely unchanged, which is a good sign of a well-implemented update.

While these changes appear to be correctly implemented, it's crucial to:

  1. Verify that all routing-related tests still function correctly with the new configuration.
  2. Run the entire test suite to ensure no regressions have been introduced.
  3. Consider updating any documentation or team guidelines related to writing tests for components that involve routing.

As you continue to modernize the testing setup, consider exploring more advanced routing configurations in your tests, such as setting up mock routes or testing navigation guards. This can lead to more robust and comprehensive test coverage for components that heavily rely on routing.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE

📥 Commits

Files that changed from the base of the PR and between 3779e88 and e5d8554.

📒 Files selected for processing (71)
  • src/test/javascript/spec/component/assessment-dashboard/exercise-assessment-dashboard.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/assessment-shared/assessment-header.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/competencies/competency-management/competency-management.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/competencies/competency-popover.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/complaints/complaints-for-tutor.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/course/course-exercises.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/course/course-management.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/course/course-overview.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/course/course-statistics/course-management-statistics.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/course/course-unenrollment/course-unenrollment-modal.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/course/course.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/course/detail/course-detail-doughnut-chart.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/exam/exam-scores/exam-scores-average-scores-graph.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/exam/exam-update.component.spec.ts (6 hunks)
  • src/test/javascript/spec/component/exam/manage/exam-students-attendance-check.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/exam/manage/exam-students.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/exam/manage/exams/exam-checklist-exercisegroup-table.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/exam/manage/exams/exam-detail.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/exam/manage/exercise-groups/exercise-groups.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/exam/manage/student-exams/student-exam-detail-table-row.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/exam/manage/student-exams/student-exam-detail.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/exam/manage/student-exams/student-exams.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/exam/participate/exam-start-information/exam-start-information.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/exam/participate/exercises/quiz-exam-submission.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/exam/participate/general-information/exam-general-information.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/exam/participate/summary/exam-result-summary.component.spec.ts (4 hunks)
  • src/test/javascript/spec/component/exam/participate/summary/result-overview/exam-result-overview.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/exam/test-run/test-run-management.component.spec.ts (4 hunks)
  • src/test/javascript/spec/component/exercises/shared/exercise-scores/exercise-scores.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/exercises/shared/exercise-statistics.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/file-upload-assessment/file-upload-assessment.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/file-upload-exercise/file-upload-exercise-detail.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/file-upload-submission/file-upload-submission.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/footer/footer.component.spec.ts (1 hunks)
  • src/test/javascript/spec/component/grading-system/grading-system.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/iris/settings/iris-course-settings-update.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/iris/settings/iris-enabled.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/iris/settings/iris-exercise-settings-update.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/lecture-unit/unit-creation-card.component.spec.ts (1 hunks)
  • src/test/javascript/spec/component/modeling-assessment-editor/modeling-assessment-editor.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/modeling-submission/modeling-submission-team.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/modeling-submission/modeling-submission.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/overview/course-conversations/layout/conversation-header/conversation-header.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/overview/course-exams/course-exams.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/overview/course-exercises/course-exercise-row.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/overview/course-lectures/course-lecture-row.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/overview/course-lectures/course-lectures.component.spec.ts (4 hunks)
  • src/test/javascript/spec/component/overview/course-statistics/course-statistics.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/overview/course-statistics/visualizations/exercise-scores-chart.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/participation-submission/participation-submission.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/programming-assessment/code-editor-tutor-assessment-container.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/shared/code-button.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/shared/main.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/shared/metis/post/post.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/shared/notification/notification-popup.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/shared/sidebar/conversation-options.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/statistics/statistics-average-score-graph.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/statistics/statistics-graph.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/statistics/statistics.component.spec.ts (1 hunks)
  • src/test/javascript/spec/component/team/teams.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/text-editor/text-editor.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/text-submission-assessment/text-submission-assessment.component.spec.ts (4 hunks)
  • src/test/javascript/spec/component/tutorial-groups/course-tutorial-groups/course-tutorial-group-card.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/tutorial-groups/shared/tutorial-group-detail.component.spec.ts (4 hunks)
  • src/test/javascript/spec/component/tutorial-groups/shared/tutorial-group-row.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/tutorial-groups/tutorial-groups-management/tutorial-group-management-resolve.service.spec.ts (2 hunks)
  • src/test/javascript/spec/integration/guided-tour/guided-tour.integration.spec.ts (2 hunks)
  • src/test/javascript/spec/service/bonus.service.spec.ts (2 hunks)
  • src/test/javascript/spec/service/grading-system.service.spec.ts (2 hunks)
  • src/test/javascript/spec/service/notification.service.spec.ts (2 hunks)
  • src/test/javascript/spec/service/user-route-access.service.spec.ts (2 hunks)
🧰 Additional context used
📓 Path-based instructions (71)
src/test/javascript/spec/component/assessment-dashboard/exercise-assessment-dashboard.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/assessment-shared/assessment-header.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/competencies/competency-management/competency-management.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/competencies/competency-popover.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/complaints/complaints-for-tutor.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/course/course-exercises.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/course/course-management.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/course/course-overview.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/course/course-statistics/course-management-statistics.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/course/course-unenrollment/course-unenrollment-modal.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/course/course.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/course/detail/course-detail-doughnut-chart.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/exam-scores/exam-scores-average-scores-graph.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/exam-update.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/manage/exam-students-attendance-check.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/manage/exam-students.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/manage/exams/exam-checklist-exercisegroup-table.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/manage/exams/exam-detail.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/manage/exercise-groups/exercise-groups.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/manage/student-exams/student-exam-detail-table-row.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/manage/student-exams/student-exam-detail.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/manage/student-exams/student-exams.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/participate/exam-start-information/exam-start-information.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/participate/exercises/quiz-exam-submission.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/participate/general-information/exam-general-information.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/participate/summary/exam-result-summary.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/participate/summary/result-overview/exam-result-overview.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exam/test-run/test-run-management.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exercises/shared/exercise-scores/exercise-scores.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/exercises/shared/exercise-statistics.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/file-upload-assessment/file-upload-assessment.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/file-upload-exercise/file-upload-exercise-detail.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/file-upload-submission/file-upload-submission.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/footer/footer.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/grading-system/grading-system.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/iris/settings/iris-course-settings-update.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/iris/settings/iris-enabled.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/iris/settings/iris-exercise-settings-update.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/lecture-unit/unit-creation-card.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/modeling-assessment-editor/modeling-assessment-editor.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/modeling-submission/modeling-submission-team.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/modeling-submission/modeling-submission.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/overview/course-conversations/layout/conversation-header/conversation-header.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/overview/course-exams/course-exams.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/overview/course-exercises/course-exercise-row.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/overview/course-lectures/course-lecture-row.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/overview/course-lectures/course-lectures.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/overview/course-statistics/course-statistics.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/overview/course-statistics/visualizations/exercise-scores-chart.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/participation-submission/participation-submission.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/programming-assessment/code-editor-tutor-assessment-container.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/shared/code-button.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/shared/main.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/shared/metis/post/post.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/shared/notification/notification-popup.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/shared/sidebar/conversation-options.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/statistics/statistics-average-score-graph.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/statistics/statistics-graph.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/statistics/statistics.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/team/teams.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/text-editor/text-editor.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/text-submission-assessment/text-submission-assessment.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/tutorial-groups/course-tutorial-groups/course-tutorial-group-card.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/tutorial-groups/shared/tutorial-group-detail.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/tutorial-groups/shared/tutorial-group-row.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/tutorial-groups/tutorial-groups-management/tutorial-group-management-resolve.service.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/integration/guided-tour/guided-tour.integration.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/service/bonus.service.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/service/grading-system.service.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/service/notification.service.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/service/user-route-access.service.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

🔇 Additional comments (159)
src/test/javascript/spec/component/tutorial-groups/shared/tutorial-group-row.component.spec.ts (2)

10-10: LGTM: RouterModule import added correctly.

The import of RouterModule from '@angular/router' is correct and aligns with the PR objective to replace the deprecated RouterTestingModule. This change follows the guideline of avoiding full module imports.


Line range hint 1-46: Summary: Changes align with PR objectives, minor improvements suggested.

The modifications to replace RouterTestingModule with RouterModule are correctly implemented and align with the PR objectives. The test setup follows most of the coding guidelines, including the use of jest and NgMocks.

To further improve the file:

  1. Consider removing the empty providers array if not needed.
  2. Enhance the test case with more specific expectations to provide better coverage and align with the expectation specificity guideline.

These minor adjustments will result in a more robust and maintainable test file.

src/test/javascript/spec/component/tutorial-groups/course-tutorial-groups/course-tutorial-group-card.component.spec.ts (2)

13-13: LGTM: RouterModule import added.

The addition of RouterModule from @angular/router aligns with the PR objective to replace the deprecated RouterTestingModule. This change is consistent with Angular's best practices for testing.


23-23: LGTM: RouterModule.forRoot([]) used in TestBed configuration.

The replacement of RouterTestingModule.withRoutes([]) with RouterModule.forRoot([]) aligns with the PR objective and Angular's best practices for testing.

[perf_improvements]
Consider mocking the router to improve test performance:

import { Router } from '@angular/router';

// In the TestBed configuration
providers: [
  {
    provide: Router,
    useValue: {
      navigate: jest.fn(),
      // Add other router methods you use in your component
    },
  },
],

This approach can lead to faster test execution and more focused unit tests.

src/test/javascript/spec/component/lecture-unit/unit-creation-card.component.spec.ts (2)

10-10: LGTM: Import change aligns with PR objectives.

The replacement of RouterTestingModule with RouterModule is in line with the PR's goal of updating the router setup in tests. This change follows Angular's best practices for testing components that depend on routing.


Line range hint 1-53: Overall impact: Minimal with improved router setup.

The changes to the router setup in this test file are minimal and don't affect the core test logic. The component initialization and event emission tests remain unchanged and should continue to function as before.

To ensure the changes haven't introduced any regressions, please run the following command to verify that all tests in this file pass:

This will help confirm that the router setup changes haven't inadvertently affected the test outcomes.

src/test/javascript/spec/component/statistics/statistics.component.spec.ts (4)

12-12: LGTM: Appropriate import for router testing.

The addition of provideRouter from @angular/router is in line with the PR objective to replace the deprecated RouterTestingModule. This change follows modern Angular testing practices.


28-28: LGTM: Updated providers with router configuration.

The addition of provideRouter([]) to the providers array is consistent with the PR objective and correctly replaces the deprecated RouterTestingModule. The existing mock services for LocalStorageService and SessionStorageService are correctly maintained.

[perf_improvements]
Consider mocking irrelevant dependencies to improve test performance. For example:

providers: [
  provideRouter([]),
  { provide: LocalStorageService, useValue: {} },
  { provide: SessionStorageService, useValue: {} },
],

This approach can potentially speed up the tests by avoiding the instantiation of MockSyncStorage for each test.


Line range hint 1-58: Summary: Router testing setup successfully updated.

The changes in this file successfully replace the deprecated RouterTestingModule with provideRouter(), aligning with the PR objectives and modern Angular testing practices. The core test logic remains unchanged, which should maintain the integrity of the existing tests.

To ensure the changes haven't inadvertently affected the test outcomes, please run the test suite and confirm all tests still pass:

#!/bin/bash
# Description: Run the test suite for StatisticsComponent

# Test: Execute the test suite
npm test -- --testPathPattern=statistics.component.spec.ts

If all tests pass, we can be confident that the router testing setup has been successfully updated without introducing any regressions.


20-20: LGTM: Simplified test module configuration.

The removal of RouterTestingModule.withRoutes([]) from the imports array is consistent with the PR objective and simplifies the test setup. This change improves code readability.

To ensure all necessary modules are still imported, let's verify the contents of ArtemisTestModule:

src/test/javascript/spec/component/shared/main.component.spec.ts (1)

2-2: LGTM: Import changes align with PR objectives

The changes in the import statements are appropriate:

  1. Consolidating imports from mock-translate.service improves code organization.
  2. Replacing RouterTestingModule with RouterModule aligns with the PR objective to remove deprecated modules.

These changes contribute to cleaner and more up-to-date code.

Also applies to: 15-15

src/test/javascript/spec/component/grading-system/grading-system.component.spec.ts (2)

9-9: LGTM: Import change aligns with PR objective.

The addition of RouterModule to the import statement is correct and necessary for the subsequent TestBed configuration change. This change aligns with the PR objective of replacing RouterTestingModule.


Line range hint 1-78: Summary: Changes successfully implement PR objective.

The modifications to this file successfully replace RouterTestingModule with RouterModule.forRoot([]), aligning with the PR objective. The existing tests remain intact and continue to cover the main component functionality. Consider the suggested minor improvements and additional test to further enhance the test suite.

src/test/javascript/spec/component/course/detail/course-detail-doughnut-chart.component.spec.ts (3)

9-9: LGTM: Import statement for provideRouter.

The addition of the import statement for provideRouter from @angular/router is correct and aligns with the PR objective of replacing RouterTestingModule.


22-22: LGTM: TestBed configuration update.

The changes to the TestBed configuration are appropriate:

  1. Removal of RouterTestingModule (not visible in the diff) aligns with the PR objective.
  2. Using MockModule for PieChartModule follows the guideline to mock irrelevant dependencies, which can improve test performance.

Line range hint 1-95: Summary: Successful update of router configuration in tests.

The changes in this file successfully replace RouterTestingModule with provideRouter, aligning with the PR objectives and Angular's latest best practices. The update is minimal and focused, affecting only the test setup without changing the actual test cases. This approach is correct as the component's behavior should remain unaffected by this change.

The file continues to adhere to the coding guidelines, using Jest for testing and following proper mocking practices (e.g., using MockModule for PieChartModule).

To ensure that RouterTestingModule has been completely removed and that no other files are still using it, run the following verification script:

✅ Verification successful

Verified: RouterTestingModule has been completely removed from spec files.

The execution of the verification script returned no results, confirming that RouterTestingModule is no longer used in any TypeScript spec files within the src/test/javascript/spec directory. This ensures that the router configuration update aligns with the PR objectives and Angular's best practices.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for any remaining usage of RouterTestingModule in spec files

# Test: Search for RouterTestingModule in spec files
rg --type typescript "RouterTestingModule" "src/test/javascript/spec"

# If the above command returns no results, it confirms that RouterTestingModule has been completely removed from spec files

Length of output: 102


Script:

#!/bin/bash
# Description: Check for any remaining usage of RouterTestingModule in spec files

# Test: Search for RouterTestingModule in TypeScript spec files
rg --type ts --type tsx "RouterTestingModule" "src/test/javascript/spec"

Length of output: 98


Script:

#!/bin/bash
# Description: Check for any remaining usage of RouterTestingModule in spec files

# Test: Search for RouterTestingModule in TypeScript spec files using glob patterns
rg "RouterTestingModule" --glob "*.ts" --glob "*.tsx" "src/test/javascript/spec"

Length of output: 78

src/test/javascript/spec/component/footer/footer.component.spec.ts (2)

7-7: LGTM: Import of RouterModule is correct.

The import of RouterModule from @angular/router is appropriate for the updated TestBed configuration. This change aligns with the PR objective of replacing RouterTestingModule.


Line range hint 1-89: Verify router functionality in tests after RouterTestingModule replacement.

The replacement of RouterTestingModule with RouterModule.forRoot([]) aligns with the PR objective. However, it's important to ensure that this change doesn't affect any router-specific functionality in the tests.

Please run the following script to check for any router-specific test cases that might be affected:

If the script returns any results, please review those test cases carefully to ensure they still function correctly with the new router configuration.

✅ Verification successful

Verified: The replacement of RouterTestingModule with RouterModule.forRoot([]) does not affect any router-specific functionality in the tests.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for router-specific test cases in FooterComponent spec

# Test: Search for router-related expectations
rg --type typescript -i '(expect.*router|router.*expect)' src/test/javascript/spec/component/footer/footer.component.spec.ts

Length of output: 161


Script:

#!/bin/bash
# Description: Check for router-specific test cases in FooterComponent spec without using --type

# Test: Search for router-related expectations in the specific spec file
rg -i '(expect.*router|router.*expect)' src/test/javascript/spec/component/footer/footer.component.spec.ts

Length of output: 108

src/test/javascript/spec/component/competencies/competency-popover.component.spec.ts (2)

10-10: LGTM: Import change aligns with PR objectives.

The replacement of RouterTestingModule with RouterModule is in line with the PR's goal of updating the routing setup in tests. This change follows current Angular best practices for testing components with routing dependencies.


Line range hint 1-91: Overall impact: Changes successfully address PR objectives.

The updates to this test file effectively replace RouterTestingModule with RouterModule.forRoot(), aligning with current Angular best practices while maintaining test integrity. The core test logic and cases remain unchanged, ensuring continued coverage of the component's functionality.

To ensure comprehensive test coverage, consider running the following command to check the current test coverage for this file:

Consider enhancing the tests with more specific expectations:

  1. Verify the content of the popover (e.g., check for the presence of specific text or elements).
  2. Test edge cases, such as when competencies is an empty array or courseId is undefined.
  3. Add tests for any component methods not currently covered.

These additions would further improve the robustness of the test suite.

src/test/javascript/spec/component/tutorial-groups/tutorial-groups-management/tutorial-group-management-resolve.service.spec.ts (4)

8-8: LGTM: Import changes align with PR objectives

The addition of provideRouter from @angular/router is in line with the PR objective of replacing RouterTestingModule. This change also adheres to the coding guideline of avoiding full module imports.


Line range hint 39-77: LGTM: Existing tests remain valid and comprehensive

The existing test cases are still valid with the new setup and follow the coding guidelines:

  • Use of jest.spyOn for mocking aligns with the mock guideline.
  • Expect statements follow the expectation specificity guideline (e.g., toHaveBeenCalledWith, not.toHaveBeenCalledWith).
  • Tests cover various scenarios for the resolve method, ensuring comprehensive testing.

The tests effectively verify the navigation behavior based on different course configurations, which is crucial for the TutorialGroupManagementResolve service.


22-24: LGTM: TestBed configuration updated correctly, but consider adding test routes

The removal of the imports array and addition of provideRouter([]) to the providers array aligns with the PR objective and follows the coding guideline to use provideRouter instead of RouterTestingModule.

However, consider whether passing an empty array to provideRouter([]) is sufficient for your testing needs. You might want to add necessary routes for comprehensive testing.

To ensure that the router configuration is sufficient for the tests, let's check if there are any route-related assertions in the test file:


Line range hint 1-77: Overall: Changes successfully implement PR objectives with minor suggestions

The changes in this file successfully replace RouterTestingModule with provideRouter, aligning with the PR objectives and coding guidelines. The existing tests remain valid and comprehensive, covering various scenarios for the TutorialGroupManagementResolve service.

Suggestions for improvement:

  1. Consider adding necessary routes to provideRouter([]) if specific route configurations are required for testing.
  2. Ensure that the removal of RouterTestingModule doesn't affect any other parts of the test setup that might have depended on it.

These changes contribute to keeping the codebase up-to-date with Angular's best practices for testing.

To ensure that the removal of RouterTestingModule doesn't affect other parts of the codebase, let's check for its usage in other test files:

This will help identify if there are other test files that still need to be updated.

src/test/javascript/spec/component/course/course-statistics/course-management-statistics.component.spec.ts (1)

Line range hint 1-78: Overall, the test file adheres to the provided coding guidelines.

The test specification for CourseManagementStatisticsComponent follows the best practices outlined in the coding guidelines:

  1. It uses Jest as the testing framework.
  2. Mock components and directives are utilized (e.g., MockComponent, MockDirective).
  3. The file avoids full module imports, using ArtemisTestModule instead.
  4. Expectations use specific matchers as recommended (e.g., toHaveBeenCalledOnce()).
  5. The StatisticsService is properly mocked for testing component logic.

The update to use RouterModule.forRoot([]) instead of RouterTestingModule is a step in the right direction. However, consider the suggestions in the previous comment to further improve the routing setup in the test environment.

src/test/javascript/spec/component/team/teams.component.spec.ts (1)

9-9: LGTM: Import changes align with PR objectives

The addition of provideRouter and removal of RouterTestingModule aligns with the PR objective to replace the deprecated RouterTestingModule. This change follows Angular's latest best practices for testing.

src/test/javascript/spec/component/overview/course-lectures/course-lecture-row.component.spec.ts (2)

14-14: LGTM: Import statement updated correctly.

The import statement has been appropriately updated to include RouterModule, which is consistent with the changes made in the TestBed configuration. This change aligns with the PR objective of replacing RouterTestingModule with alternatives.


Line range hint 1-124: Overall assessment: Changes successfully implement PR objectives.

The modifications to this test file successfully replace the deprecated RouterTestingModule with RouterModule.forRoot(), aligning with the PR's main objective. The changes are minimal and focused, maintaining the existing test structure while updating the routing configuration.

Key points:

  1. The import statements have been correctly updated.
  2. The TestBed configuration now uses RouterModule.forRoot() instead of RouterTestingModule.
  3. Existing test cases remain unchanged, ensuring continued coverage of component functionality.

These changes effectively modernize the test setup without altering the core testing logic, maintaining the integrity of the test suite.

src/test/javascript/spec/component/iris/settings/iris-enabled.component.spec.ts (2)

14-14: LGTM: Import statement for provideRouter added correctly.

The import of provideRouter from '@angular/router' is correctly added and aligns with the PR objective of replacing RouterTestingModule with alternatives like provideRouter().


Line range hint 1-105: Overall changes look good, aligning with PR objectives.

The replacement of RouterTestingModule with provideRouter([]) has been implemented correctly. This change:

  1. Aligns with the PR objective of updating deprecated router testing modules.
  2. Maintains the existing test functionality without introducing breaking changes.
  3. Follows the coding guidelines for mocking dependencies and avoiding full module imports.

The test cases remain unchanged and should continue to function as expected with this new router configuration.

To ensure that RouterTestingModule has been completely removed from this file, run the following command:

This command should return no results, confirming the complete removal of RouterTestingModule.

src/test/javascript/spec/component/statistics/statistics-graph.component.spec.ts (2)

15-15: LGTM: Import statement for provideRouter added.

The addition of provideRouter import aligns with the PR objective of replacing RouterTestingModule. This change is necessary for the updated router configuration in the test setup.


Line range hint 1-124: Verify that all tests pass with the new router configuration.

The changes to the router configuration appear to have no negative impact on the existing tests. The test cases and their logic remain unchanged, which is a good indication that the router change was non-breaking. However, it's crucial to ensure that all tests still pass with the new configuration.

Please run the following command to verify that all tests in this file pass:

If all tests pass, it confirms that the router configuration change has not introduced any regressions.

src/test/javascript/spec/component/exam/participate/general-information/exam-general-information.component.spec.ts (3)

2-2: LGTM: Import statement for provideRouter added correctly.

The import of provideRouter from '@angular/router' is appropriate for the updated test setup using the new Angular router configuration approach.


Line range hint 1-146: Summary of review for exam-general-information.component.spec.ts

  1. The change from RouterTestingModule to provideRouter is appropriate and aligns with modern Angular testing practices.
  2. Existing tests appear unaffected, but verification of test coverage is recommended.
  3. Suggestions for improving test isolation and setup have been provided.
  4. Overall, the file maintains good test coverage and organization.

Please address the suggestions and verify test coverage to ensure the continued reliability and maintainability of these tests.


Line range hint 54-146: Verify test coverage and functionality with the new router setup.

The existing test cases appear to be unaffected by the router configuration change, which is good. However, it's important to ensure that:

  1. All tests still pass with the new setup.
  2. There's no loss of coverage due to the removal of RouterTestingModule.

Please run the following commands to verify:

If all tests pass and coverage is maintained, no further action is needed. Otherwise, please review and update the affected tests.

src/test/javascript/spec/component/iris/settings/iris-exercise-settings-update.component.spec.ts (1)

12-12: LGTM: Import of provideRouter added correctly.

The addition of provideRouter from '@angular/router' is appropriate for updating the routing configuration in the test environment. This change aligns with modern Angular testing practices and prepares for the replacement of RouterTestingModule.

src/test/javascript/spec/component/exam/manage/exam-students-attendance-check.component.spec.ts (2)

2-2: LGTM: Import changes align with PR objectives

The changes to the import statements are in line with the PR's objective to replace the deprecated RouterTestingModule. Adding provideRouter and Observable while removing RouterTestingModule is the correct approach for updating the testing setup.

Also applies to: 14-14


Line range hint 1-114: Overall file review: Tests remain intact and consistent

The test cases and their implementations remain unchanged, which is appropriate given the PR's focused objective. The component initialization, error handling, sorting functionality, and interaction with ExamManagementService are still being tested as before.

To ensure that the changes haven't inadvertently affected the tests, please run the following verification script:

This will help confirm that the router configuration changes haven't introduced any unexpected issues.

src/test/javascript/spec/component/exam/manage/student-exams/student-exam-detail-table-row.component.spec.ts (2)

26-26: LGTM: Import of provideRouter added.

The addition of provideRouter import is in line with the PR objective to replace RouterTestingModule. This change aligns with modern Angular testing practices.


Line range hint 1-93: Overall, the file adheres to best practices and coding guidelines.

The changes made to replace RouterTestingModule with provideRouter are appropriate and align with the PR objectives. The file continues to follow best practices for Angular testing, including:

  1. Using Jest for testing
  2. Mocking irrelevant dependencies
  3. Avoiding full module imports
  4. Using appropriate assertion methods (e.g., toEqual, toHaveBeenCalledOnce)

No additional issues or improvements are identified beyond the previously mentioned suggestions.

src/test/javascript/spec/component/exercises/shared/exercise-statistics.component.spec.ts (1)

22-22: LGTM: Import statement for RouterModule added.

The addition of the RouterModule import is correct and necessary for the updated TestBed configuration. This change aligns with the PR objective of replacing RouterTestingModule.

src/test/javascript/spec/component/course/course-unenrollment/course-unenrollment-modal.component.spec.ts (2)

16-16: LGTM: Import statement updated correctly.

The change from RouterTestingModule to Router and provideRouter aligns with the PR objective and follows Angular's latest best practices for testing components with routing dependencies.


Line range hint 1-124: Overall assessment: Changes are appropriate and maintain test integrity.

The updates to this test file successfully replace the deprecated RouterTestingModule with provideRouter, as per the PR objectives. The changes are minimal and focused, affecting only the import statements and TestBed configuration. All existing test cases remain intact, ensuring that the component's behavior is still thoroughly validated.

Some observations:

  1. The test coverage appears to be unchanged, which aligns with the PR notes.
  2. The existing tests cover various scenarios including button state, alerts, navigation, and enrollment status checks.
  3. The use of mock providers and specific expectations (e.g., toBeTrue, toHaveBeenCalledOnce) adheres to the coding guidelines.

To ensure that similar changes have been applied consistently across the codebase, you may want to run the following verification script:

This script will help identify any spec files that might have been missed in the transition from RouterTestingModule to provideRouter.

✅ Verification successful

Verification Successful: RouterTestingModule has been fully replaced with provideRouter.

All spec files have been updated accordingly:

  • No instances of RouterTestingModule remain.
  • provideRouter is consistently used across all relevant spec files.

These changes ensure that routing is properly configured in tests, maintaining the integrity and functionality of the test suite.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for any remaining usage of RouterTestingModule in spec files

# Test: Search for RouterTestingModule in spec files
echo "Checking for remaining RouterTestingModule usage in spec files:"
rg --type typescript "RouterTestingModule" "src/test/javascript/spec"

# Test: Verify provideRouter is used in place of RouterTestingModule
echo "Verifying provideRouter usage in spec files:"
rg --type typescript "provideRouter" "src/test/javascript/spec"

Length of output: 435


Script:

#!/bin/bash
# Description: Check for any remaining usage of RouterTestingModule in spec files

# Test: Search for RouterTestingModule in spec files
echo "Checking for remaining RouterTestingModule usage in spec files:"
rg "RouterTestingModule" --glob '*.spec.ts' src/test/javascript/spec

# Test: Verify provideRouter is used in place of RouterTestingModule
echo "Verifying provideRouter usage in spec files:"
rg "provideRouter" --glob '*.spec.ts' src/test/javascript/spec

Length of output: 12679

src/test/javascript/spec/component/iris/settings/iris-course-settings-update.component.spec.ts (2)

11-11: LGTM: Import statement updated correctly.

The import statement has been updated to include provideRouter, which aligns with the PR objective of replacing RouterTestingModule. This change follows the coding guideline to avoid full module imports and only includes the necessary functions.


Line range hint 1-114: Overall assessment: Changes align with PR objectives, but consider additional testing.

The changes made to replace RouterTestingModule with provideRouter align well with the PR objectives and coding guidelines. The existing tests still cover the component's functionality, which is good.

However, I have a few suggestions:

  1. Consider adding a specific test case to verify that the new routing setup works as expected with the component. This would ensure that the transition from RouterTestingModule to provideRouter hasn't introduced any unforeseen issues.

  2. Review the existing test cases to ensure they are still relevant and comprehensive given the routing changes. While they appear to be intact, it's worth double-checking that they still effectively test all aspects of the component's interaction with routing.

  3. Ensure that the test coverage for this file remains high, as mentioned in the PR objectives. You might want to run a coverage report to confirm this.

To help verify the impact of these changes, you can run the following script:

This script will help ensure that RouterTestingModule has been completely replaced and that the test coverage for this file remains high.

src/test/javascript/spec/component/overview/course-exercises/course-exercise-row.component.spec.ts (2)

35-35: LGTM: Correct replacement of RouterTestingModule

The change from RouterTestingModule to RouterModule aligns with the PR objective to replace the deprecated module. This import is necessary for the subsequent router configuration and follows the coding guideline of avoiding full module imports.


Line range hint 1-138: Overall assessment: Changes are well-implemented and align with PR objectives

The modifications in this file successfully replace the deprecated RouterTestingModule with RouterModule and its appropriate configuration. The changes maintain the existing test structure while updating the routing setup to align with current Angular best practices. The implementation follows the coding guidelines and PR objectives.

To further improve the code:

  1. Consider extracting the routes configuration to a separate constant for better maintainability.
  2. Ensure that all tests pass with these changes, especially those that might have depended on specific RouterTestingModule behavior.
  3. Update any documentation or comments that might reference the old RouterTestingModule usage.

To verify that all tests are passing and that there are no remaining references to RouterTestingModule, you can run the following commands:

src/test/javascript/spec/service/user-route-access.service.spec.ts (2)

3-3: LGTM: Import changes align with PR objectives.

The addition of RouterModule import and removal of RouterTestingModule import align with the PR objective of replacing the deprecated RouterTestingModule. This change follows the coding guideline of avoiding full module imports.


Line range hint 1-148: Summary: Successfully replaced RouterTestingModule with minimal impact.

The changes in this file successfully replace the deprecated RouterTestingModule with RouterModule.forRoot(), aligning with the PR objectives. The test suite structure and individual test cases remain unchanged, which should maintain the existing test coverage.

Key points:

  1. Import statements have been updated appropriately.
  2. TestBed configuration now uses RouterModule.forRoot() for routing setup.
  3. The changes follow the coding guidelines and best practices.

While the current implementation works, consider the suggestion to use provideRouter() for a more lightweight setup in the test environment. Overall, these changes effectively modernize the routing configuration in the test suite without altering its functionality.

src/test/javascript/spec/component/exam/participate/exam-start-information/exam-start-information.component.spec.ts (3)

17-17: LGTM: Import statement for provideRouter added.

The addition of the provideRouter import is correct and aligns with the PR objective of replacing the deprecated RouterTestingModule.


Line range hint 55-180: LGTM: Existing test cases remain valid and comprehensive.

The unchanged test cases continue to provide thorough coverage of the ExamStartInformationComponent's functionality. They correctly use specific expectations as per the coding guidelines.

[perf_improvements]
Consider mocking irrelevant dependencies to improve test performance. For example, you could mock the ArtemisSharedModule, ArtemisSharedComponentModule, and ArtemisExamSharedModule instead of importing them directly. This can be done using MockModule from ng-mocks:

import { MockModule } from 'ng-mocks';

// In the TestBed configuration
imports: [
    MockModule(ArtemisSharedModule),
    MockModule(ArtemisSharedComponentModule),
    MockModule(ArtemisExamSharedModule)
],

This change can potentially speed up the test execution by reducing the number of dependencies that need to be initialized.


Line range hint 1-180: Summary: Successfully updated router testing setup while maintaining test integrity.

The changes in this file successfully address the PR objective of replacing the deprecated RouterTestingModule with provideRouter. The update aligns with Angular's latest best practices for testing and maintains the integrity of the existing test cases.

Key points:

  1. The provideRouter import and usage are correctly implemented.
  2. Existing tests remain valid and comprehensive, covering various aspects of the ExamStartInformationComponent.
  3. The changes do not introduce any regressions in the test coverage or functionality.

Minor suggestions for improvement:

  1. Consider restructuring the TestBed configuration for better readability.
  2. Explore mocking module dependencies to potentially improve test performance.

Overall, these changes effectively modernize the test setup while preserving the thorough validation of the component's functionality.

src/test/javascript/spec/component/exam/exam-scores/exam-scores-average-scores-graph.component.spec.ts (3)

18-18: LGTM: Import statement added correctly.

The import of RouterModule is correctly added and is consistent with the changes made in the TestBed configuration.


Line range hint 61-73: Consider mocking irrelevant dependencies.

While the current implementation is good, there might be room for performance improvement by mocking irrelevant dependencies:

[perf_improvements]

  1. If CourseManagementService.find() is not directly relevant to these tests, consider mocking it with a simple stub:

    MockProvider(CourseManagementService, {
        find: jest.fn(),
    }),
  2. Similarly, if TranslateService methods are not directly used in these tests, consider using a minimal mock:

    MockProvider(TranslateService, {
        // Add only the methods that are actually used in these tests
    }),

These changes can potentially speed up test execution by reducing unnecessary setup.


Line range hint 1-153: Summary of the review

The changes made to replace RouterTestingModule with RouterModule.forRoot([]) are appropriate and align with the PR objectives. The test suite structure remains intact, and the tests continue to validate the component's behavior correctly.

Key points:

  1. The import and usage of RouterModule are correct.
  2. The test cases follow the coding guidelines, using Jest and appropriate mocking.
  3. Some minor improvements have been suggested for more specific Jest matchers and more effective mocking.
  4. Consider the suggested performance improvements by mocking irrelevant dependencies.

Overall, the changes are approved with some minor suggestions for improvement.

src/test/javascript/spec/component/course/course-exercises.component.spec.ts (1)

17-17: LGTM: Import statement updated correctly.

The import statement has been updated to include RouterModule from '@angular/router', which aligns with the PR objective to replace RouterTestingModule. This change is necessary for the subsequent modification in the TestBed configuration.

src/test/javascript/spec/component/overview/course-lectures/course-lectures.component.spec.ts (5)

3-3: LGTM: Import statement updated correctly.

The import statement has been updated to include RouterModule along with ActivatedRoute. This change aligns with the PR objective of replacing RouterTestingModule and is necessary for the updated TestBed configuration.


11-12: LGTM: Import paths simplified.

The import paths for CourseLecturesComponent and SidebarComponent have been simplified, improving code readability and maintainability. This change follows the best practice of using shorter, more concise import paths.


24-26: LGTM: Import statements updated and added correctly.

The import paths for CourseOverviewService and ProfileService have been simplified, improving code readability. The addition of provideHttpClient is necessary for the updated TestBed configuration, aligning with the PR objective of updating the testing setup.


28-28: LGTM: ProfileInfo import added.

The addition of the ProfileInfo import is necessary for the mock ProfileService setup later in the file. This change follows the good practice of importing only what's needed for the test.


31-31: LGTM: provideHttpClientTesting import added.

The addition of the provideHttpClientTesting import is necessary for the updated TestBed configuration. This change aligns with the PR objective of updating the testing setup and modernizing the HTTP client testing approach.

src/test/javascript/spec/component/file-upload-exercise/file-upload-exercise-detail.component.spec.ts (2)

61-61: LGTM: TestBed configuration updated correctly

The changes to the TestBed configuration correctly implement the replacement of RouterTestingModule with provideRouter([]). This aligns with the PR objective and follows Angular's latest best practices for testing.

Also applies to: 71-71


Line range hint 1-180: Summary of review

The changes in this file successfully replace RouterTestingModule with provideRouter, aligning with the PR objectives. The modifications to the import statements and TestBed configuration are correct and follow Angular's latest best practices for testing.

However, there are two points that need attention:

  1. Remove the unnecessary empty import statement from '@angular/router/testing'.
  2. Verify the completeness of routing tests, ensuring that all necessary routing functionality is still adequately tested either in this file or in related test files.

Once these points are addressed, the changes in this file will be fully approved.

src/test/javascript/spec/component/shared/sidebar/conversation-options.component.spec.ts (1)

29-29: LGTM: Import of provideRouter added correctly.

The addition of provideRouter import is in line with the PR objective of replacing RouterTestingModule. This change allows for a more direct configuration of routes in the test setup.

src/test/javascript/spec/component/exam/manage/exams/exam-checklist-exercisegroup-table.component.spec.ts (2)

15-15: LGTM: Import change for router configuration.

The import of provideRouter from @angular/router is correct and aligns with the updated testing approach, replacing the previously used RouterTestingModule.


Line range hint 1-153: Overall assessment: Changes look good, with room for improvement.

The updates to the TestBed configuration successfully replace the deprecated RouterTestingModule with provideRouter, aligning with current Angular best practices. The existing tests remain intact and should continue to function as expected.

Key points:

  1. Router configuration has been correctly updated.
  2. Existing tests are unaffected and still valid.
  3. The file adheres to the provided coding guidelines for test files.

Suggestions for improvement:

  1. Consider reordering the providers as suggested earlier for better readability.
  2. Add router-related tests to ensure the new configuration is working as expected and to improve overall test coverage.

These changes effectively address the PR objective of replacing the deprecated RouterTestingModule while maintaining the functionality of the existing tests.

src/test/javascript/spec/component/course/course-management.component.spec.ts (2)

27-27: LGTM: Correct import for provideRouter.

The import of provideRouter from '@angular/router' is correct and aligns with the PR objective of replacing RouterTestingModule.


Line range hint 1-186: Verify that all existing tests still pass.

The changes to the routing configuration are minimal and focused. However, it's important to ensure that these changes haven't inadvertently affected the existing tests.

Please run the following command to verify that all tests in this file still pass:

If any tests fail, please review and update them accordingly.

src/test/javascript/spec/component/tutorial-groups/shared/tutorial-group-detail.component.spec.ts (3)

113-113: Approve RouterModule.forRoot([]) usage and verify test coverage.

The replacement of RouterTestingModule with RouterModule.forRoot([]) is consistent with the previous change and aligns with the PR objective.

To ensure this change doesn't affect test coverage, please run the following command:

#!/bin/bash
# Description: Verify test coverage for TutorialGroupDetailComponent

# Test: Check if all tests in TutorialGroupDetailComponent are still passing
jest --testNamePattern="TutorialGroupDetailComponent" --coverage

Line range hint 1-180: Summary: Approve changes and suggest final verification.

The changes in this file successfully replace RouterTestingModule with RouterModule.forRoot([]), aligning with the PR objectives. The implementation is consistent and improves the test setup by using standard Angular router configuration.

To ensure all tests are passing after these changes, please run the following command:

#!/bin/bash
# Description: Verify all tests in the file are passing

# Test: Run all tests in the file
jest src/test/javascript/spec/component/tutorial-groups/shared/tutorial-group-detail.component.spec.ts

If all tests pass, these changes can be confidently merged.


61-61: Approve RouterModule.forRoot([]) usage and verify test coverage.

The replacement of RouterTestingModule with RouterModule.forRoot([]) aligns with the PR objective and is a valid approach for setting up routing in tests.

To ensure this change doesn't affect test coverage, please run the following command:

src/test/javascript/spec/component/overview/course-statistics/visualizations/exercise-scores-chart.component.spec.ts (4)

8-8: LGTM: Import changes align with PR objectives.

The import of provideRouter is consistent with the goal of replacing RouterTestingModule. The ActivatedRoute import is likely a reorganization rather than a new addition.


45-48: LGTM: TestBed configuration updated correctly.

The changes in the TestBed configuration are consistent with the PR objectives:

  1. The imports have been reorganized.
  2. provideRouter([]) has been added to the providers array, replacing the previous RouterTestingModule.

The empty array passed to provideRouter is appropriate for component testing where specific routes are not needed.


Line range hint 1-210: Summary: Router testing module replacement implemented correctly.

The changes in this file successfully replace the RouterTestingModule with provideRouter() as intended. The modifications are minimal and focused, affecting only the routing configuration in the test setup. The core test logic remains unchanged, which is a positive sign.

However, it's crucial to:

  1. Verify that all tests still pass after these changes.
  2. Ensure that the test coverage remains the same or improves.
  3. Check for any potential breaking changes or unintended side effects in the broader test suite.

These verifications will help maintain the integrity and effectiveness of the test suite while modernizing the routing setup.


Line range hint 1-210: Verify test coverage and potential breaking changes.

While the changes are minimal and focused on updating the routing configuration for tests, it's important to ensure that:

  1. The test coverage remains the same or improves after these changes.
  2. There are no breaking changes introduced by the transition from RouterTestingModule to provideRouter.

Consider running the entire test suite and comparing the coverage reports before and after these changes.

To verify the test coverage and potential breaking changes, you can run the following script:

src/test/javascript/spec/component/exam/test-run/test-run-management.component.spec.ts (5)

1-1: LGTM: Import statements updated correctly.

The changes to the import statements align with the PR objective of replacing RouterTestingModule. The shift to provideHttpClient and RouterModule is consistent with modern Angular testing practices and follows the latest Angular documentation.

Also applies to: 4-4


31-31: LGTM: HttpClientTesting provider imported.

The addition of provideHttpClientTesting is a good practice when using provideHttpClient for testing. This ensures comprehensive HTTP testing capabilities in the test environment.


52-52: LGTM: RouterModule correctly configured for testing.

The replacement of RouterTestingModule with RouterModule.forRoot([]) aligns with the PR objective and provides an appropriate routing configuration for the test environment.


64-65: LGTM: HTTP testing providers correctly added.

The addition of provideHttpClient() and provideHttpClientTesting() to the TestBed providers ensures a proper setup for HTTP testing in the Angular environment. This is consistent with modern testing practices and the changes made to the imports.


Line range hint 1-190: Summary: Test setup successfully modernized.

The changes in this file successfully update the testing setup to align with modern Angular practices:

  1. Replaced deprecated RouterTestingModule with RouterModule.forRoot([]).
  2. Updated HTTP testing configuration using provideHttpClient and provideHttpClientTesting.
  3. Imports and TestBed configuration have been appropriately adjusted.

These changes meet the PR objectives and adhere to the coding guidelines. The core functionality and structure of the tests remain unchanged, ensuring that the component's behavior is still properly validated.

src/test/javascript/spec/component/overview/course-conversations/layout/conversation-header/conversation-header.component.spec.ts (2)

30-30: LGTM: Import statement for provideRouter.

The addition of the provideRouter import from @angular/router is correct and aligns with the PR objective of replacing RouterTestingModule.


Line range hint 1-185: Verify the impact of routing changes on existing tests.

The overall structure and logic of the test cases remain unchanged, which is good for maintaining existing test coverage. However, it's crucial to ensure that all routing-related tests still function correctly with the new provideRouter configuration.

Please run the following script to check if any tests are failing after these changes:

Additionally, please manually verify that the following test case still passes and correctly asserts the navigation:

  1. The test case that checks navigation for channels with subtypes (around line 145).
  2. Any other tests that rely on routing functionality.

Consider adding more specific routing tests to ensure the new provideRouter configuration works as expected in all scenarios covered by the component.

src/test/javascript/spec/component/shared/metis/post/post.component.spec.ts (2)

29-29: LGTM: Import statement updated correctly.

The addition of provideRouter to the import statement is consistent with the changes in the testing setup. This update aligns with modern Angular testing practices.


Line range hint 1-268: Summary: Router testing approach successfully updated.

The changes in this file are minimal and focused on updating the router testing approach. The replacement of RouterTestingModule with provideRouter([]) is the key modification, which aligns the test setup with modern Angular testing practices.

The existing tests remain unchanged and appear to cover various aspects of the PostComponent functionality comprehensively. These include:

  • Sorting of answers
  • Presence of header and footer components
  • Correct initialization of post content and titles
  • Opening of modals
  • Navigation to different routes based on user actions

The update to the router testing approach should not affect the existing test coverage or functionality. However, it's important to ensure that all tests still pass after these changes.

To verify that the changes haven't introduced any regressions, please run the following command and ensure all tests pass:

src/test/javascript/spec/service/grading-system.service.spec.ts (1)

Line range hint 1-290: Verify that all tests still pass with the new configuration.

The test cases remain unchanged, which is correct as they don't directly interact with the router. The use of HttpTestingController is still valid and follows best practices for service testing.

Please run the following command to ensure all tests still pass with the new configuration:

src/test/javascript/spec/component/shared/notification/notification-popup.component.spec.ts (2)

3-3: LGTM: Import statement updated correctly.

The import statement has been appropriately modified to include RouterModule, which is necessary for the updated test configuration. This change aligns with the PR objective to replace RouterTestingModule.


Line range hint 1-214: LGTM: Test suite structure and content are well-maintained.

The overall structure and content of the test suite remain robust and comprehensive:

  1. The tests cover various scenarios including initialization, click events, and websocket receive events.
  2. The logic for generating and handling notifications is intact and well-tested.
  3. The test assertions align with our coding guidelines, using appropriate Jest expectation methods.

The changes made to accommodate the new router setup don't affect the quality or coverage of the tests, which is commendable.

src/test/javascript/spec/integration/guided-tour/guided-tour.integration.spec.ts (2)

45-45: LGTM: Import statement for RouterModule added correctly.

The import of RouterModule from @angular/router is appropriate and necessary for the subsequent use of RouterModule.forRoot(). This change aligns with the PR objective of replacing RouterTestingModule.


Line range hint 64-69: LGTM: RouterModule.forRoot() used correctly.

The replacement of RouterTestingModule with RouterModule.forRoot() is appropriate and aligns with the PR objectives. The route configuration for the CoursesComponent looks correct.

To ensure this change doesn't introduce any unexpected behavior, please verify that all routing-related tests still pass. Run the following command to check for any failing tests related to routing:

src/test/javascript/spec/component/exam/manage/exam-students.component.spec.ts (3)

3-3: LGTM: Import statement updated correctly.

The addition of provideRouter to the import statement is in line with the PR objective of replacing RouterTestingModule. This change aligns with modern Angular testing practices.


73-73: LGTM: TestBed configuration updated correctly.

The addition of provideRouter([]) to the providers array in the TestBed.configureTestingModule setup is consistent with the PR objective. This change correctly replaces the deprecated RouterTestingModule with the modern provideRouter approach. The empty array passed to provideRouter is appropriate for unit testing components where no specific routes are needed.


Line range hint 1-248: Overall assessment: Changes are appropriate and well-implemented.

The modifications to replace RouterTestingModule with provideRouter have been correctly implemented. These changes align with the PR objectives and modern Angular testing practices. The core functionality of the tests remains unchanged, which is appropriate for this type of update. Consider the earlier suggestion to enhance router-related test coverage to further improve the robustness of the test suite.

src/test/javascript/spec/component/exam/participate/exercises/quiz-exam-submission.component.spec.ts (2)

27-27: LGTM: Import statement for provideRouter added correctly.

The import of provideRouter from '@angular/router' is correctly placed and necessary for the updated router configuration in the test setup.


Line range hint 1-265: Verify that all tests pass with the new router configuration.

The changes made to this file are minimal and focused on updating the router testing approach. The existing tests remain unchanged, which suggests that the new router configuration should not affect the test behavior. However, it's important to ensure that all tests still pass with the new setup.

Please run the following command to verify that all tests in this file pass:

If any tests fail, please review and update them accordingly.

src/test/javascript/spec/component/competencies/competency-management/competency-management.component.spec.ts (3)

7-7: LGTM: Import statement updated correctly.

The import statement has been updated to include provideRouter from @angular/router, which aligns with the PR objective of replacing RouterTestingModule. This change is consistent with modern Angular testing practices.


49-49: LGTM: TestBed configuration updated correctly.

The TestBed configuration has been updated to remove RouterTestingModule from imports and add provideRouter([]) to the providers array. This change is consistent with the import changes and aligns with the PR objective of replacing RouterTestingModule. The empty array passed to provideRouter is appropriate for this component test.

Also applies to: 63-63


Line range hint 1-278: Overall changes look good and adhere to guidelines.

The changes in this file are focused on updating the router configuration for testing, which aligns with the PR objective. The test cases remain unchanged and continue to cover the component's behavior comprehensively. The file adheres to the coding guidelines for test files, including the use of jest, NgMocks, and other specified practices.

Some observations:

  1. The test cases cover various scenarios, including loading competencies, handling modal interactions, and managing competency relations.
  2. Mocks and spies are used appropriately to isolate the component under test.
  3. The file structure and naming conventions are consistent with the guidelines.

No issues or concerns were identified in the rest of the file.

src/test/javascript/spec/component/exam/manage/exercise-groups/exercise-groups.component.spec.ts (2)

3-3: LGTM: Import statement updated correctly.

The import statement has been updated to include provideRouter, which aligns with the PR objective of replacing RouterTestingModule. This change also adheres to the coding guideline of avoiding full module imports.


Line range hint 1-280: Summary: Router configuration updated successfully.

The changes made to this test file successfully replace the deprecated RouterTestingModule with provideRouter(), as per the PR objectives. The modifications are minimal and focused, affecting only the import statement and the TestBed configuration.

Key points:

  1. The import statement now includes provideRouter.
  2. The TestBed configuration uses provideRouter([]) in the providers array.
  3. Existing tests remain unchanged, which is appropriate as the router configuration update should not affect their logic.

These changes align with the coding guidelines by avoiding full module imports and mocking irrelevant dependencies. The test file structure and coverage appear to be maintained.

To ensure that the router configuration change hasn't inadvertently affected any tests, please run the test suite for this component and verify that all tests pass successfully.

src/test/javascript/spec/component/course/course.component.spec.ts (2)

4-4: LGTM: Import changes align with PR objective.

The import statement has been correctly updated to include RouterModule, which is necessary for the new routing setup using RouterModule.forRoot(). This change aligns with the PR objective of replacing RouterTestingModule.


Line range hint 1-300: Summary: RouterTestingModule replacement successful with minor improvement suggested.

The changes in this file successfully address the PR objective of replacing RouterTestingModule. The import statements and TestBed configuration have been updated appropriately. The overall structure and logic of the tests remain intact, which is positive.

A minor improvement has been suggested to use provideRouter() instead of RouterModule.forRoot() for a more lightweight test setup. This change would further optimize the testing environment without affecting the test coverage or functionality.

Overall, the changes are minimal, focused, and achieve the intended goal while maintaining the integrity of the existing tests.

src/test/javascript/spec/component/overview/course-exams/course-exams.component.spec.ts (1)

2-2: LGTM: Import statement updated correctly.

The change from RouterTestingModule to RouterModule aligns with the PR objective of replacing the deprecated RouterTestingModule. This update is correct and necessary for the new TestBed configuration.

src/test/javascript/spec/component/text-editor/text-editor.component.spec.ts (2)

3-3: LGTM: Import statement updated correctly.

The import statement has been updated to include RouterModule, which aligns with the PR objective of replacing the deprecated RouterTestingModule. This change is consistent with the transition to using standard Angular router setup for testing.


Line range hint 1-324: LGTM: Changes align with PR objective, with suggestions for improvement.

The changes in this file successfully replace the deprecated RouterTestingModule with RouterModule, aligning with the PR objective. The test suite remains functional and follows most of the coding guidelines for test files.

Summary of suggestions for improvement:

  1. Consider using provideRouter() instead of RouterModule.forRoot() for a more lightweight testing setup.
  2. Explore the use of NgMocks for more effective and maintainable component mocking.

These suggestions aim to enhance the test suite's efficiency and maintainability. Overall, the changes are approved with these recommendations for future improvements.

src/test/javascript/spec/component/statistics/statistics-average-score-graph.component.spec.ts (2)

15-15: LGTM: Import statement for provideRouter added correctly.

The import of provideRouter from @angular/router is correct and aligns with the latest Angular practices for configuring routing in tests. This change successfully addresses the PR objective of replacing the deprecated RouterTestingModule.


Line range hint 1-324: Overall assessment: Changes successfully address PR objectives.

The updates to this test file effectively replace the deprecated RouterTestingModule with provideRouter, aligning with the PR objectives. The changes are minimal and focused, maintaining the existing test structure and functionality. No further modifications are necessary for this file to meet the PR goals.

To ensure that all references to RouterTestingModule have been removed from this file, run the following command:

This command should return no results, confirming that the deprecated module has been completely removed from this test file.

✅ Verification successful

Verification Successful: RouterTestingModule has been completely removed.

The executed command confirmed that there are no remaining instances of RouterTestingModule in statistics-average-score-graph.component.spec.ts. This ensures that the deprecated module has been fully replaced with provideRouter, aligning with the PR objectives. No further action is required for this file.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

rg "RouterTestingModule" src/test/javascript/spec/component/statistics/statistics-average-score-graph.component.spec.ts

Length of output: 119

src/test/javascript/spec/component/exam/manage/exams/exam-detail.component.spec.ts (2)

6-6: LGTM: Import statement updated correctly.

The import statement has been updated to include RouterModule, which is necessary for the new routing configuration using RouterModule.forRoot(). This change aligns with the PR objective of replacing RouterTestingModule.


Line range hint 1-324: Overall assessment: Changes improve test setup while maintaining functionality.

The modifications to this test file successfully replace the deprecated RouterTestingModule with RouterModule.forRoot(), as per the PR objectives. The new routing configuration provides a more comprehensive setup for testing various exam-related functionalities.

Key points:

  1. Import statements have been correctly updated.
  2. Routing configuration has been enhanced with detailed test routes.
  3. Existing tests remain intact, ensuring continued coverage of component functionality.

These changes improve the test setup while maintaining the overall structure and effectiveness of the test suite. The transition aligns well with Angular's latest best practices for testing components with routing dependencies.

src/test/javascript/spec/component/exam/participate/summary/result-overview/exam-result-overview.component.spec.ts (1)

25-25: LGTM: Import statement for provideRouter added correctly.

The import of provideRouter from @angular/router is correctly added and aligns with the updated test configuration.

src/test/javascript/spec/component/exam/manage/student-exams/student-exam-detail.component.spec.ts (2)

11-11: LGTM: Import change aligns with PR objective

The addition of RouterModule to the import statement is consistent with the PR's goal of replacing RouterTestingModule. This change supports the new routing configuration in the test setup.


Line range hint 1-380: Overall changes are minimal and focused

The modifications in this file are limited to updating the import statement and the TestBed configuration to replace RouterTestingModule with RouterModule. These changes align with the PR objectives and maintain the existing test structure and behavior.

To ensure that these changes haven't inadvertently affected other parts of the codebase, let's verify the usage of RouterTestingModule:

✅ Verification successful

To ensure there are no remaining usages of RouterTestingModule in spec files, please run the following script:


No remaining usages of RouterTestingModule found

The search confirmed that there are no remaining usages of RouterTestingModule in the spec files.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining usage of RouterTestingModule in spec files
rg --type typescript 'RouterTestingModule' 'src/test/javascript/spec'

Length of output: 102


Script:

#!/bin/bash
# Search for any remaining usage of RouterTestingModule in spec files
rg 'RouterTestingModule' 'src/test/javascript/spec' --glob '*.spec.ts'

Length of output: 68

src/test/javascript/spec/service/bonus.service.spec.ts (3)

11-11: LGTM: Import change aligns with PR objective

The addition of provideRouter import and removal of RouterTestingModule aligns with the PR objective of replacing the deprecated RouterTestingModule. This change follows Angular's latest best practices for setting up routing in tests.


94-95: LGTM: TestBed configuration updated correctly

The TestBed configuration has been updated correctly:

  1. The imports array is now empty, removing the deprecated RouterTestingModule.
  2. provideRouter([]) has been added to the providers array, setting up a router with no routes.
  3. The existing HTTP client setup is maintained.

These changes align with Angular's latest testing practices and the PR objective.


Line range hint 1-438: Overall changes look good, suggest verification of test suite

The changes successfully replace the deprecated RouterTestingModule with provideRouter, aligning with the PR objective. The modifications are minimal and focused, maintaining the integrity of the existing test cases. This approach should preserve the test coverage and functionality.

To ensure the changes haven't inadvertently affected the test suite:

If all tests pass, we can be confident that the routing setup changes haven't introduced any regressions.

src/test/javascript/spec/component/assessment-shared/assessment-header.component.spec.ts (3)

27-27: LGTM: Import of RouterModule added.

The addition of the RouterModule import is correct and necessary for the updated TestBed configuration.


Line range hint 1-453: Run full test suite to ensure no regressions.

While the changes made to replace RouterTestingModule with RouterModule.forRoot([]) appear to be correct and shouldn't affect the existing tests in this file, it's important to run the entire test suite to ensure there are no unexpected regressions in other components or tests that might depend on router functionality.

Please run the full test suite and verify that all tests pass:

#!/bin/bash
# Run the full test suite
npm test

# If you want to focus on client-side tests only, you can use:
# npm run test:client

# Check for any test failures
if [ $? -ne 0 ]; then
    echo "Some tests failed. Please review the output above."
else
    echo "All tests passed successfully."
fi

52-52: Verify router-dependent tests after replacing RouterTestingModule.

The replacement of RouterTestingModule with RouterModule.forRoot([]) is correct and aligns with the PR objective. This change provides a minimal router configuration for testing, which should be sufficient for most cases.

Please verify that all router-dependent tests still pass with this change. Run the following command to check for any failing tests:

src/test/javascript/spec/component/file-upload-submission/file-upload-submission.component.spec.ts (2)

8-8: LGTM: Import statement updated correctly.

The replacement of RouterTestingModule with RouterModule aligns with the PR objective and follows Angular's latest best practices for testing.


Line range hint 1-424: Overall changes look good, but verify test coverage.

The changes to replace RouterTestingModule with RouterModule have been implemented correctly and consistently throughout the file. The core functionality of the tests remains unchanged, which is good for maintaining the existing test coverage.

To ensure that the new routing setup doesn't affect the test outcomes, please run the following verification:

This script will run the tests for the FileUploadSubmissionComponent and check for any failures or changes in behavior. It will also compare the execution time with previous runs to detect any performance regressions.

src/test/javascript/spec/component/complaints/complaints-for-tutor.component.spec.ts (2)

20-20: LGTM: Import change aligns with PR objective

The addition of provideRouter import and removal of RouterTestingModule import are consistent with the PR objective of replacing the deprecated RouterTestingModule.


Line range hint 1-453: LGTM: Existing tests remain unchanged

The test cases and their logic remain unchanged, which is a good indication that they were not tightly coupled to the specific implementation of the router module. This suggests that the change from RouterTestingModule to provideRouter([]) doesn't affect the existing functionality being tested.

To ensure that the routing functionality is still properly tested, please run the following command and verify that all tests pass:

If all tests pass, it confirms that the routing change hasn't introduced any regressions.

src/test/javascript/spec/component/exercises/shared/exercise-scores/exercise-scores.component.spec.ts (4)

4-4: LGTM: Updated import for router testing

The import statement has been correctly updated to include provideRouter from @angular/router. This change aligns with modern Angular testing practices and prepares for the removal of RouterTestingModule.


123-123: LGTM: Removed RouterTestingModule from imports

The RouterTestingModule.withRoutes([]) has been correctly removed from the imports in the TestBed configuration. This change is consistent with the PR objective of replacing the deprecated RouterTestingModule.


139-139: LGTM: Added provideRouter to providers

The provideRouter([]) has been correctly added to the providers array in the TestBed configuration. This change provides the necessary routing configuration for the tests and is consistent with the removal of RouterTestingModule. The empty array passed to provideRouter maintains the equivalent functionality of the previous RouterTestingModule.withRoutes([]).


Line range hint 1-424: Verify that all tests pass with the updated configuration

The changes to the router testing configuration look good and align with the PR objectives. However, it's important to ensure that these changes haven't inadvertently affected the test results.

Please run the following command to verify that all tests in this file still pass:

src/test/javascript/spec/component/shared/code-button.component.spec.ts (2)

31-31: LGTM: Appropriate replacement for RouterTestingModule

The addition of provideRouter import and removal of RouterTestingModule aligns with the PR objective of updating the routing setup in tests. This change follows Angular's latest best practices for testing components with routing dependencies.


Line range hint 1-458: Verify impact of routing changes on existing tests

The replacement of RouterTestingModule with provideRouter is a significant change in the test setup. While the test cases themselves remain unchanged, it's crucial to ensure that this modification doesn't inadvertently affect any existing tests.

Please run the following script to check if any tests are failing after this change:

If any tests fail, please review them carefully to ensure they're not related to the routing changes. If they are, consider updating the affected tests to work with the new provideRouter setup.

src/test/javascript/spec/component/participation-submission/participation-submission.component.spec.ts (4)

8-8: Import change looks good.

The updated import statement correctly includes RouterModule, which is necessary for the new router configuration in the test setup.


Line range hint 1-458: Summary of changes and recommendations

The changes in this file successfully replace the deprecated RouterTestingModule with RouterModule.forRoot([]), which aligns with the PR objective. However, to ensure the integrity of the test suite, please:

  1. Verify that all existing tests pass with the new router configuration.
  2. Review router-dependent tests for any unexpected behavior.
  3. Consider adding new tests specifically for routing functionality if they don't already exist.

These steps will help maintain the reliability of the test suite while updating to the latest Angular best practices.


91-91: Verify impact of router configuration change on tests.

The replacement of RouterTestingModule with RouterModule.forRoot([]) is in line with the PR objective. However, please ensure that this change doesn't affect the routing behavior in the existing tests.

To verify the impact, run the following script:


Line range hint 1-458: Review router-dependent tests for potential issues.

While the existing test cases weren't modified, the change in router configuration from RouterTestingModule to RouterModule.forRoot([]) might affect how routing works in the tests. Please review all router-dependent tests to ensure they still function correctly with the new configuration.

Pay special attention to:

  1. The beforeEach block where the router is initialized.
  2. Test cases that involve navigation or route parameters.
  3. Any mocks or stubs related to the ActivatedRoute or Router.

To assist in this review, run the following script to identify potentially affected tests:

src/test/javascript/spec/component/overview/course-statistics/course-statistics.component.spec.ts (1)

3-3: LGTM: Import statement updated correctly.

The import statement has been updated to replace RouterTestingModule with provideRouter. This change aligns with the PR objective of updating the routing setup in tests.

src/test/javascript/spec/component/exam/manage/student-exams/student-exams.component.spec.ts (3)

2-2: LGTM: Import changes align with updated Angular testing practices.

The replacement of RouterTestingModule with provideRouter is a good update that follows the latest Angular testing recommendations. This change simplifies the routing setup in tests and provides more flexibility.


51-51: LGTM: TestBed configuration updated correctly.

The TestBed configuration has been properly updated to use provideRouter([]) in the providers array instead of RouterTestingModule.withRoutes([]) in the imports array. This change correctly implements the new way of setting up routing in the test environment.

Also applies to: 211-211


Line range hint 1-590: Verify that all tests pass with the new routing configuration.

While the changes to the routing configuration are correct, it's crucial to ensure that all existing tests still pass with the new setup. Please run the entire test suite to confirm that the replacement of RouterTestingModule with provideRouter hasn't inadvertently affected any test cases.

src/test/javascript/spec/component/modeling-submission/modeling-submission-team.component.spec.ts (3)

11-11: Import statement updated to align with new routing setup.

The import statement has been updated to replace RouterTestingModule with RouterModule. This change aligns with the PR objective of replacing the deprecated RouterTestingModule.


Line range hint 1-524: Review existing tests for compatibility with new routing setup.

While the main changes have been made to accommodate the new routing setup, it's important to ensure that all existing tests are still valid and comprehensive. Some tests might rely on specific behavior of the RouterTestingModule that may not be present in the new setup.

To verify the compatibility and coverage of the existing tests with the new routing setup, please run the following script:

#!/bin/bash
# Description: Analyze test coverage and identify potential gaps after routing changes

# Test: Check for any usage of RouterTestingModule in other test files
rg -t typescript "RouterTestingModule" src/test/javascript/spec

# Test: Verify if there are any router-related tests that might need updating
rg -t typescript "router\." src/test/javascript/spec/component/modeling-submission/modeling-submission-team.component.spec.ts

# Note: Review the output to identify any areas that might need attention

If any occurrences of RouterTestingModule are found in other test files, or if there are router-related tests in this file, consider updating them to align with the new routing setup.


67-67: TestBed configuration updated for new routing setup.

The TestBed configuration has been updated to use RouterModule.forRoot([routes[0]]) instead of RouterTestingModule. This change reflects the new approach to setting up routing in the test environment.

To ensure that this change doesn't affect the test coverage or behavior, please run the following script:

✅ Verification successful

TestBed configuration successfully updated.
All relevant imports have been correctly modified to use RouterModule.forRoot([routes[0]]), and RouterTestingModule is no longer present in the test configuration.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that all tests still pass with the new routing setup

# Test: Run the tests for this specific component
ng test --include=src/test/javascript/spec/component/modeling-submission/modeling-submission-team.component.spec.ts

# Note: Check the output to ensure all tests are passing

Length of output: 261


Script:

#!/bin/bash
# Description: Verify that RouterTestingModule is no longer used and the new routing setup is correctly implemented

# Check if RouterTestingModule is still imported
rg -t ts 'RouterTestingModule' src/test/javascript/spec

# Check if RouterModule.forRoot is used in TestBed configuration
rg -t ts 'RouterModule\.forRoot' src/test/javascript/spec/component/modeling-submission/modeling-submission-team.component.spec.ts

Length of output: 265

src/test/javascript/spec/component/exam/participate/summary/exam-result-summary.component.spec.ts (3)

1-1: Excellent update to modern Angular testing practices!

The changes in the import statements reflect a shift towards using provider-based setup instead of module-based imports. This approach offers better flexibility and granular control over the testing environment.

  1. Replacing HttpClientModule with provideHttpClient allows for more precise HTTP testing setup.
  2. Adding provideRouter enables custom routing configuration in tests without the need for RouterTestingModule.
  3. Importing provideHttpClientTesting facilitates mock HTTP testing without the full HttpClientTestingModule.

These updates align well with Angular's latest best practices for testing.

Also applies to: 4-4, 58-58


Line range hint 1-585: Overall, good progress towards modern Angular testing practices

The changes made to this test file represent a significant step towards adopting modern Angular testing practices. The shift from module-based to provider-based testing setup improves flexibility and granular control over the testing environment.

Key improvements:

  1. Updated import statements to use provider functions instead of modules.
  2. Refactored the sharedSetup function to use providers instead of imports.

Areas for further improvement:

  1. Standardize mocking approaches across the file.
  2. Ensure consistent use of asynchronous testing methods.

These changes have enhanced the maintainability and flexibility of the test suite. Addressing the suggested improvements will further increase the consistency and readability of the tests.

Great job on modernizing the testing approach!


Line range hint 246-266: Verify if this test case needs updates

While no changes were made to this test case, it's important to ensure that it still functions correctly with the new provider-based setup. Please verify that:

  1. The ThemeService is properly provided and can be mocked as before.
  2. The exportToPDFButton can still be queried and clicked as expected.
  3. The tick() function and fakeAsync wrapper are still appropriate for this test case.

If everything works as expected, no changes are needed. However, it's worth double-checking to ensure the test's reliability.

src/test/javascript/spec/component/text-submission-assessment/text-submission-assessment.component.spec.ts (1)

20-20: LGTM: Import changes for router testing

The changes to the imports are correct and align with modern Angular testing practices. Removing RouterTestingModule and adding provideRouter is the right approach for the updated testing setup.

Also applies to: 29-29

src/test/javascript/spec/service/notification.service.spec.ts (2)

5-5: LGTM: Updated router import for modern Angular testing

The addition of provideRouter import and the removal of RouterTestingModule (as implied by the summary) align with current best practices for Angular testing. This change simplifies the test setup and keeps it up-to-date with Angular's latest recommendations.


Line range hint 1-589: LGTM: Successful migration to modern Angular testing practices

The changes made to this test file successfully migrate it to use modern Angular testing practices:

  1. Updated router setup using provideRouter.
  2. Updated HTTP client setup using provideHttpClient and provideHttpClientTesting.

These changes don't affect the existing test cases, which should continue to function as before. The migration improves the test setup without introducing any regressions or requiring changes to the test logic.

To ensure that the changes haven't introduced any unintended side effects, please run the following command to execute these tests:

This will run only the tests in this file. Verify that all tests pass successfully.

src/test/javascript/spec/component/course/course-overview.component.spec.ts (3)

Line range hint 1-167: LGTM: Well-organized imports and mock data setup.

The imports are comprehensive, covering all necessary testing utilities and components. The mock data for courses, exercises, and exams is well-defined, providing a solid foundation for the test cases. The inclusion of a ControlsTestingComponent for specific testing scenarios is a good practice.


Line range hint 170-715: LGTM: Comprehensive test coverage for CourseOverviewComponent.

The test suite provides extensive coverage for the CourseOverviewComponent, including:

  • Initialization and lifecycle methods
  • Course loading and error handling
  • Exam visibility and competencies
  • Websocket subscriptions
  • UI element rendering and interactions
  • Exam mode behavior

The use of fakeAsync and tick for handling asynchronous operations is appropriate and ensures accurate testing of time-dependent functionality.


Line range hint 1-718: Overall: Well-structured and comprehensive test suite with one configuration issue.

This test file for CourseOverviewComponent is well-organized and provides extensive coverage of the component's functionality. The test cases are thorough and cover various aspects including initialization, course loading, UI interactions, and exam mode behavior.

The main point for improvement is the incorrect placement of RouterModule.forRoot([]) in the TestBed configuration, which should be moved from the declarations array to the imports array.

After addressing this issue, the test suite will be in excellent shape to ensure the reliability and correctness of the CourseOverviewComponent.

src/test/javascript/spec/component/file-upload-assessment/file-upload-assessment.component.spec.ts (3)

10-10: Update import statement to use RouterModule instead of RouterTestingModule.

The import statement has been updated to use RouterModule from @angular/router instead of RouterTestingModule from @angular/router/testing. This change aligns with the transition from using RouterTestingModule to RouterModule.forRoot() in the test configuration.


Line range hint 1-1000: Verify router-related tests with the new RouterModule configuration.

With the change from RouterTestingModule to RouterModule.forRoot(), it's important to ensure that all router-related tests are still functioning correctly. Pay special attention to the following areas:

  1. Tests involving router.navigate() or router.navigateByUrl().
  2. Tests that check for URL changes or route parameters.
  3. Any tests that rely on ActivatedRoute or its properties.

To help identify potentially affected tests, run the following command:

#!/bin/bash
# Description: Find tests that might be affected by the router configuration change
rg --type typescript -i '(router\.navigate|router\.navigateByUrl|activatedRoute)' src/test/javascript/spec/component/file-upload-assessment/file-upload-assessment.component.spec.ts

Please review the output and ensure that these tests are still working as expected with the new RouterModule.forRoot() configuration.


74-74: Replace RouterTestingModule with RouterModule.forRoot() in TestBed configuration.

The test configuration has been updated to use RouterModule.forRoot([routes[0]]) instead of RouterTestingModule. This change allows for more precise control over the routing configuration in the test environment.

However, there are a few considerations:

  1. Make sure that routes[0] contains all the necessary routes for the tests to function correctly.
  2. Be aware that this change might affect how navigation and route-related functionalities are tested.

To ensure that all necessary routes are included, let's check the routes array:

src/test/javascript/spec/component/exam/exam-update.component.spec.ts (2)

7-7: LGTM: Updated imports for modern Angular testing

The changes to import provideRouter, provideHttpClient, and provideHttpClientTesting are good updates. These align with the modern Angular testing recommendations, moving away from module-based testing to a provider-based approach.

Also applies to: 9-9, 45-45


Line range hint 1-846: Overall: Excellent modernization of Angular testing setup

The changes made to this test file are focused on updating the Angular testing setup to use the provider-based approach instead of the module-based approach. This modernization is consistent throughout the file and aligns with current Angular best practices. These updates should make the tests more maintainable and potentially more performant.

Key improvements:

  1. Updated imports to include provideRouter, provideHttpClient, and provideHttpClientTesting.
  2. Removed RouterTestingModule and HttpClientModule from test configurations.
  3. Added provider-based setup for routing and HTTP client in both "create and edit exams" and "import exams" test suites.

These changes do not alter the core logic of the tests, which is good as it maintains the original test coverage while improving the testing infrastructure.

src/test/javascript/spec/component/assessment-dashboard/exercise-assessment-dashboard.component.spec.ts (4)

Line range hint 1-213: Approval: RouterTestingModule replacement implemented correctly.

The change from RouterTestingModule to RouterModule.forRoot([]) in the imports array is correct and aligns with the PR objective. This update moves away from the deprecated RouterTestingModule and uses the standard Angular router configuration for testing, which is a positive step towards maintaining up-to-date and best practice testing methodologies.


Line range hint 388-1012: Run full test suite and update tests if necessary.

The extensive test suite for ExerciseAssessmentDashboardComponent covers a wide range of functionalities, which is commendable. However, with the change from RouterTestingModule to RouterModule.forRoot([]), it's crucial to ensure all tests still pass and accurately reflect the component's behavior.

Please run the full test suite and verify that all tests pass with the new router configuration. If any tests fail or behave unexpectedly, update them to accommodate the new setup while maintaining test coverage.

#!/bin/bash
# Run the full test suite for ExerciseAssessmentDashboardComponent
npm test -- --testPathPattern="exercise-assessment-dashboard.component.spec.ts"

Line range hint 1-1012: Summary: RouterTestingModule replacement implemented, verify overall test integrity.

The main change in this file is the replacement of RouterTestingModule with RouterModule.forRoot([]), which aligns with the PR objective. This is a positive step towards updating the testing methodology. The extensive test suite covering various aspects of the ExerciseAssessmentDashboardComponent has been maintained, which is commendable.

To ensure the integrity of the tests and the component's functionality:

  1. Run the entire test suite and verify all tests pass with the new configuration.
  2. Manually test the ExerciseAssessmentDashboardComponent in various scenarios to ensure its behavior remains consistent with expectations.
  3. If any discrepancies are found, update the relevant tests or component code as necessary.

This thorough validation will help maintain the reliability and accuracy of the test suite with the updated router configuration.

#!/bin/bash
# Run the full test suite and check for any failures
npm test -- --testPathPattern="exercise-assessment-dashboard.component.spec.ts" > test_output.txt
if grep -q "FAIL" test_output.txt; then
    echo "Some tests failed. Please review the output in test_output.txt"
else
    echo "All tests passed successfully."
fi

Line range hint 364-386: Verify test case compatibility with new router configuration.

While this test case for component initialization remains unchanged, it's crucial to ensure it still passes with the new RouterModule.forRoot([]) configuration. Please verify that all aspects of the initialization process, including user identity, course ID, exam ID, exercise ID, and graph setup, function correctly with the updated router setup.

src/test/javascript/spec/component/programming-assessment/code-editor-tutor-assessment-container.component.spec.ts (3)

35-35: Approve routing configuration update and suggest verification.

The change from RouterTestingModule to provideRouter aligns with modern Angular testing practices. This update should provide more flexibility in configuring routes for tests.

To ensure the new routing configuration works as expected across the test suite, please run the following command:

Also applies to: 40-40

✅ Verification successful

Routing configuration updated uses provideRouter consistently.

The change from RouterTestingModule to provideRouter has been correctly applied across all test files, ensuring consistency with modern Angular testing practices.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that all test files have been updated to use provideRouter instead of RouterTestingModule

# Search for any remaining usage of RouterTestingModule in test files
rg --type typescript -g '*.spec.ts' 'RouterTestingModule'

# Search for the new usage of provideRouter in test files
rg --type typescript -g '*.spec.ts' 'provideRouter'

Length of output: 179


Script:

#!/bin/bash
# Description: Verify that all test files have been updated to use provideRouter instead of RouterTestingModule

# Search for any remaining usage of RouterTestingModule in test files
rg --glob '*.spec.ts' 'RouterTestingModule'

# Search for the new usage of provideRouter in test files
rg --glob '*.spec.ts' 'provideRouter'

Length of output: 12393


176-176: Approve TestBed configuration update and suggest route-related test review.

The TestBed configuration has been updated to use provideRouter([]) instead of RouterTestingModule. This change is consistent with the import modifications and reflects modern Angular testing practices.

To ensure that all route-related tests are still functioning correctly with this new configuration, please run the following command:

Please review the output carefully to ensure that these tests are still valid with the new routing configuration.

Also applies to: 207-207


Line range hint 1-1000: Suggest running the full test suite to verify no regressions.

While the individual test cases appear unaffected by the routing configuration change, it's crucial to ensure that all tests, especially those involving routing, still pass with the new setup.

Please run the following command to execute the entire test suite and verify that all tests pass:

If any tests fail, please review them carefully to determine if they are related to the routing configuration change.

Copy link
Contributor

@pzdr7 pzdr7 left a comment

Choose a reason for hiding this comment

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

There are some empty imports that we could remove. Can you also check if declaration / import is correct?

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🧹 Outside diff range comments (4)
src/test/javascript/spec/component/file-upload-exercise/file-upload-exercise-detail.component.spec.ts (1)

Line range hint 1-180: Overall LGTM with a minor suggestion

The changes to replace RouterTestingModule with provideRouter have been implemented correctly without affecting the core test logic. The file maintains good test coverage for both course and exam exercises, and follows jest testing framework guidelines.

As a minor suggestion for improved organization, consider grouping related test cases using nested describe blocks. For example, you could group the "onInit with course exercise" and "onInit with exam exercise" tests under a parent describe block for initialization tests.

Example:

describe('Initialization tests', () => {
  describe('onInit with course exercise', () => {
    // ... existing tests ...
  });

  describe('onInit with exam exercise', () => {
    // ... existing tests ...
  });
});

This organization can make the test structure more clear and easier to navigate, especially as more tests are added in the future.

src/test/javascript/spec/component/course/course-overview.component.spec.ts (2)

Line range hint 268-691: LGTM: Comprehensive test coverage with well-structured test cases.

The test suite covers a wide range of functionality for the CourseOverviewComponent, including initialization, course loading, exam visibility, competencies, and UI interactions. The use of fakeAsync and tick for handling asynchronous operations is appropriate.

Consider adding more specific error handling tests, especially for network errors or unexpected server responses. This could improve the robustness of the test suite. For example:

it('should handle network errors when loading the course', fakeAsync(() => {
  findOneForDashboardStub.mockReturnValue(throwError(() => new Error('Network error')));
  const alertService = TestBed.inject(AlertService);
  const alertServiceSpy = jest.spyOn(alertService, 'addAlert');

  component.loadCourse().subscribe(
    () => {
      fail('should not succeed');
    },
    (error) => {
      expect(error).toBeDefined();
      expect(error.message).toBe('Network error');
    }
  );

  tick();

  expect(alertServiceSpy).toHaveBeenCalledWith({
    type: 'danger',
    msg: 'artemisApp.course.errors.loadFailed'
  });
}));

This test specifically checks how the component handles network errors and ensures that the appropriate alert is displayed to the user.


Line range hint 692-728: LGTM: Thorough testing of exam mode and dropdown functionality.

The final part of the test suite covers important aspects such as exam mode, dropdown functionality, and proper cleanup of subscriptions. The tests for updating recently accessed courses and unsubscribing from subscriptions demonstrate good attention to detail in managing component lifecycle and state.

Consider adding tests for edge cases, such as:

  1. Testing behavior when switching between exam and non-exam modes multiple times.
  2. Verifying the component's behavior with an empty course list or when all courses are hidden.

Example test case:

it('should handle switching between exam and non-exam modes multiple times', () => {
  const examParticipationService = TestBed.inject(ExamParticipationService);
  const examStartedSubject = new Subject<boolean>();
  (examParticipationService as any).examIsStarted$ = examStartedSubject.asObservable();

  fixture.detectChanges();
  expect(component.isExamStarted).toBeFalse();

  examStartedSubject.next(true);
  fixture.detectChanges();
  expect(component.isExamStarted).toBeTrue();
  expect(fixture.nativeElement.querySelector('.exam-wrapper')).not.toBeNull();

  examStartedSubject.next(false);
  fixture.detectChanges();
  expect(component.isExamStarted).toBeFalse();
  expect(fixture.nativeElement.querySelector('.exam-wrapper')).toBeNull();

  examStartedSubject.next(true);
  fixture.detectChanges();
  expect(component.isExamStarted).toBeTrue();
  expect(fixture.nativeElement.querySelector('.exam-wrapper')).not.toBeNull();
});

This test ensures that the component correctly handles multiple transitions between exam and non-exam modes, which could reveal potential issues with state management or UI updates.

src/test/javascript/spec/component/programming-assessment/code-editor-tutor-assessment-container.component.spec.ts (1)

Line range hint 669-669: Consider adding a basic routing test

While the changes are primarily in the test setup and don't introduce new component functionality, it might be beneficial to add a simple test to verify that the routing is set up correctly with the new provideRouter configuration. This could help ensure that the transition from RouterTestingModule to provideRouter doesn't introduce any subtle issues.

Here's a suggested test to add:

it('should have a properly configured router', () => {
  const router = TestBed.inject(Router);
  expect(router).toBeTruthy();
  expect(router.config).toEqual([]);
});

This test will verify that the Router is properly injected and configured with an empty routes array, as specified in the provideRouter([]) setup.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE

📥 Commits

Files that changed from the base of the PR and between e5d8554 and 81b451f.

📒 Files selected for processing (6)
  • src/test/javascript/spec/component/course/course-overview.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/file-upload-exercise/file-upload-exercise-detail.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/footer/footer.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/programming-assessment/code-editor-tutor-assessment-container.component.spec.ts (3 hunks)
  • src/test/javascript/spec/component/tutorial-groups/course-tutorial-groups/course-tutorial-group-card.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/tutorial-groups/shared/tutorial-group-detail.component.spec.ts (3 hunks)
🧰 Additional context used
📓 Path-based instructions (6)
src/test/javascript/spec/component/course/course-overview.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/file-upload-exercise/file-upload-exercise-detail.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/footer/footer.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/programming-assessment/code-editor-tutor-assessment-container.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/tutorial-groups/course-tutorial-groups/course-tutorial-group-card.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/tutorial-groups/shared/tutorial-group-detail.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

🔇 Additional comments (17)
src/test/javascript/spec/component/tutorial-groups/course-tutorial-groups/course-tutorial-group-card.component.spec.ts (2)

12-12: LGTM: RouterModule import added correctly.

The RouterModule import has been added correctly, replacing the previously used RouterTestingModule. This change aligns with the PR objective and resolves the issue of the empty import mentioned in past reviews.


Line range hint 1-48: Summary: Changes align well with PR objectives.

The modifications in this file successfully replace the deprecated RouterTestingModule with RouterModule, as intended by the PR objectives. The test structure remains intact, and the changes adhere to Angular testing best practices. No further changes are required for this file.

The updates ensure that the CourseTutorialGroupCardComponent tests remain functional and up-to-date with Angular's current recommendations for routing in test environments.

src/test/javascript/spec/component/footer/footer.component.spec.ts (3)

7-7: LGTM: Import of RouterModule is correct.

The addition of import { RouterModule } from '@angular/router'; is appropriate for the subsequent use of RouterModule.forRoot([]) in the TestBed configuration. This aligns with the PR objective of replacing the deprecated RouterTestingModule.


16-16: LGTM: Correct implementation of RouterModule for testing.

The addition of RouterModule.forRoot([]) to the imports array is correct and aligns with Angular's best practices for testing. This successfully replaces the deprecated RouterTestingModule and addresses the PR objective.

Note: This change correctly addresses a past review comment that suggested moving RouterModule.forRoot([]) to the imports array.


17-17: Remove unnecessary empty providers array.

The addition of an empty providers array is unnecessary and adds clutter to the code. If there are no specific providers to be added, this line can be safely removed.

Please apply the following change:

- providers: [],

This will keep the TestBed configuration concise and focused on the necessary components.

Note: This suggestion aligns with a past review comment that is still valid.

src/test/javascript/spec/component/file-upload-exercise/file-upload-exercise-detail.component.spec.ts (2)

2-2: LGTM: Import statement updated correctly

The import statement has been updated to include provideRouter from @angular/router, which aligns with the PR objective of replacing RouterTestingModule. The unnecessary empty import mentioned in the past review comment has been removed.


60-60: LGTM: TestBed configuration updated correctly

The TestBed configuration has been updated to remove RouterTestingModule from the imports array and add provideRouter([]) to the providers array. This change aligns with the PR objective and simplifies the test module configuration while maintaining the necessary routing setup.

Also applies to: 70-70

src/test/javascript/spec/component/tutorial-groups/shared/tutorial-group-detail.component.spec.ts (4)

23-23: LGTM: RouterModule import added correctly.

The import of RouterModule from '@angular/router' is correctly added. This aligns with the changes in the test configuration where RouterModule.forRoot([]) is now used.

Regarding the past comment about an empty import:

  • The empty import import {} from '@angular/router/testing'; is no longer present in the code.
  • This change correctly addresses the previous review comment.

60-60: LGTM: Correct replacement of RouterTestingModule.

The change from RouterTestingModule to RouterModule.forRoot([]) is correct and aligns with the PR objective. This modification:

  1. Removes the deprecated RouterTestingModule.
  2. Uses RouterModule.forRoot([]) which is more aligned with actual Angular application setup.
  3. The empty array passed to forRoot() is appropriate for tests as we don't need actual routes.

This change also adheres to the coding guideline of avoiding full module imports, which can improve test performance.


112-112: LGTM: Consistent replacement of RouterTestingModule.

The change from RouterTestingModule to RouterModule.forRoot([]) in the TutorialGroupDetailComponent test configuration is correct and consistent with the previous change in the file. This modification:

  1. Maintains consistency across test suites.
  2. Aligns with the PR objective of replacing the deprecated RouterTestingModule.
  3. Adheres to the coding guideline of avoiding full module imports.

23-23: Summary: All changes are approved and consistent.

The changes in this file consistently replace RouterTestingModule with RouterModule.forRoot([]) in both test suites. These modifications:

  1. Align with the PR objective of removing the deprecated RouterTestingModule.
  2. Improve the test setup by using a more standard routing configuration.
  3. Adhere to the coding guidelines, particularly avoiding full module imports.
  4. Maintain consistency across different test suites in the file.

The new import statement and its usage in both test configurations are correct and appropriate for the testing context. No issues or concerns were identified during this review.

Also applies to: 60-60, 112-112

src/test/javascript/spec/component/course/course-overview.component.spec.ts (3)

Line range hint 1-167: LGTM: Comprehensive test setup and mock data.

The imports and initial setup for the CourseOverviewComponent test suite are well-organized and thorough. The mock data for courses, exercises, and exams provides a good foundation for the tests.


Line range hint 167-267: LGTM: Well-configured TestBed with proper routing setup.

The TestBed configuration is comprehensive and includes all necessary imports, declarations, and providers. The addition of RouterModule.forRoot([]) to the imports array is a good practice for testing components that depend on routing, ensuring that the router is properly initialized in the test environment.


Line range hint 1-728: Overall, excellent test coverage with room for minor improvements.

This test suite for the CourseOverviewComponent is comprehensive and well-structured. It covers a wide range of functionality, including initialization, course loading, exam visibility, competencies, and UI interactions. The use of Angular testing utilities and Jest is appropriate, and the tests follow good practices for isolating behaviors and handling asynchronous operations.

Key strengths:

  1. Thorough setup with mock data and services
  2. Proper use of TestBed and Angular testing utilities
  3. Good coverage of component lifecycle and state management
  4. Attention to both synchronous and asynchronous operations

Recommendations for further improvement:

  1. Add more specific error handling tests, especially for network errors or unexpected server responses
  2. Include tests for edge cases, such as empty course lists or multiple exam mode transitions
  3. Consider adding performance tests for computationally intensive operations, if any

Overall, this test suite provides a solid foundation for ensuring the reliability and correctness of the CourseOverviewComponent.

src/test/javascript/spec/component/programming-assessment/code-editor-tutor-assessment-container.component.spec.ts (3)

35-35: Approve updated routing import for testing

The change from RouterTestingModule to provideRouter aligns with modern Angular testing practices. This update allows for more flexible and efficient routing configuration in the test environment.


175-175: Approve updated TestBed configuration for routing

The TestBed configuration has been correctly updated to use provideRouter([]) in the providers array instead of RouterTestingModule in the imports array. This change is consistent with the updated import and reflects the modern approach to setting up routing in Angular tests.

Also applies to: 206-206


Line range hint 1-669: Verify compatibility with existing tests

The changes to the routing configuration appear to be compatible with the existing test cases. No modifications were required for the individual tests, and the router is still injected and used in the same way throughout the file. This suggests that the transition to provideRouter was seamless and didn't introduce any breaking changes to the test suite.

To ensure full compatibility, please run the following command to check if all tests in this file pass:

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🧹 Outside diff range comments (1)
src/test/javascript/spec/component/text-submission-assessment/text-submission-assessment.component.spec.ts (1)

Line range hint 1-1024: Summary: RouterTestingModule successfully replaced with provideRouter

The changes in this file successfully replace RouterTestingModule with provideRouter(), aligning with the PR objectives. The modifications are minimal and focused, which is good for maintaining the existing test coverage. The import statement and TestBed configuration have been updated correctly.

To further improve the code:

  1. Consider moving the provideRouter([]) to a separate constant at the top of the file for better maintainability.
  2. It might be beneficial to add a test case specifically for routing to ensure the new configuration works as expected.

Overall, the changes look good and should not negatively impact the existing tests.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE

📥 Commits

Files that changed from the base of the PR and between 81b451f and e1cb2bb.

📒 Files selected for processing (2)
  • src/test/javascript/spec/component/modeling-submission/modeling-submission.component.spec.ts (2 hunks)
  • src/test/javascript/spec/component/text-submission-assessment/text-submission-assessment.component.spec.ts (3 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
src/test/javascript/spec/component/modeling-submission/modeling-submission.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

src/test/javascript/spec/component/text-submission-assessment/text-submission-assessment.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

🔇 Additional comments (3)
src/test/javascript/spec/component/modeling-submission/modeling-submission.component.spec.ts (2)

11-11: LGTM! Import changes are correct and address previous comments.

The replacement of RouterTestingModule with RouterModule is in line with the PR objectives. The removal of the empty import from '@angular/router/testing' addresses the previous review comment about the unnecessary empty import.


63-63: LGTM! TestBed configuration updated correctly.

The replacement of RouterTestingModule.withRoutes with RouterModule.forRoot is correct and aligns with the PR objectives. This change ensures that the routing configuration in the test environment matches the standard Angular routing setup.

src/test/javascript/spec/component/text-submission-assessment/text-submission-assessment.component.spec.ts (1)

20-20: LGTM: Import statement updated correctly

The import statement has been correctly updated to include provideRouter from '@angular/router'. This change aligns with the PR objective of replacing RouterTestingModule with provideRouter().

pzdr7
pzdr7 previously approved these changes Oct 8, 2024
Copy link
Contributor

@pzdr7 pzdr7 left a comment

Choose a reason for hiding this comment

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

Code

JohannesStoehr
JohannesStoehr previously approved these changes Oct 8, 2024
Copy link
Contributor

@JohannesStoehr JohannesStoehr left a comment

Choose a reason for hiding this comment

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

Refactoring looks good to me

@JohannesWt JohannesWt dismissed stale reviews from JohannesStoehr and pzdr7 via f4b46bf October 8, 2024 12:25
Copy link
Contributor

@N0W0RK N0W0RK left a comment

Choose a reason for hiding this comment

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

Code

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE

📥 Commits

Files that changed from the base of the PR and between e1cb2bb and f4b46bf.

📒 Files selected for processing (1)
  • src/test/javascript/spec/component/shared/notification/notification-popup.component.spec.ts (2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
src/test/javascript/spec/component/shared/notification/notification-popup.component.spec.ts (1)

Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}

🔇 Additional comments (1)
src/test/javascript/spec/component/shared/notification/notification-popup.component.spec.ts (1)

3-3: LGTM: Import statement updated correctly.

The addition of RouterModule to the import statement is consistent with the changes in the TestBed configuration and aligns with the PR objective of replacing RouterTestingModule.

Comment on lines +55 to 57
imports: [ArtemisTestModule, RouterModule.forRoot([])],
declarations: [NotificationPopupComponent, MockPipe(ArtemisTranslatePipe)],
providers: [
Copy link

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

⚠️ Potential issue

Update TestBed configuration to align with best practices.

While the replacement of RouterTestingModule with RouterModule.forRoot([]) aligns with the PR objective, there are a few improvements we can make:

  1. According to our coding guidelines, we should avoid full module imports in tests. Instead of using RouterModule.forRoot([]), consider using provideRouter() for a more lightweight setup.

  2. The addition of MockPipe(ArtemisTranslatePipe) to declarations is unexpected and potentially redundant, as ArtemisTranslatePipe is already provided in the providers array.

Here's a suggested improvement:

TestBed.configureTestingModule({
    imports: [ArtemisTestModule],
    declarations: [NotificationPopupComponent],
    providers: [
        // ... existing providers
        provideRouter([])
    ],
})

This change will maintain the necessary routing setup while adhering to our testing best practices and avoiding redundancy.

Copy link
Contributor

@pzdr7 pzdr7 left a comment

Choose a reason for hiding this comment

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

Reapprove

@krusche krusche changed the title Development: Remove router testing module as it is deprecated Development: Remove deprecated router module in client tests Oct 8, 2024
@krusche krusche added this to the 7.6.0 milestone Oct 8, 2024
@krusche krusche merged commit b6b47e7 into develop Oct 8, 2024
20 of 23 checks passed
@krusche krusche deleted the chore/remove-router-testing-module branch October 8, 2024 14:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Status: Done
Development

Successfully merging this pull request may close these issues.

5 participants