Angular problem creation [Project Based Front-end]

Here are the steps to create a Project Based Front-end problem using the Angular framework on the platform:

TABLE OF CONTENTS

• 1. Landing on the Dashboard
• 2. Navigating to Problem Creation
• 3. Configuring Basic Problem Details (Required)
• 4. Setting Up the Project
• 5. Upload using the ZIP method
• 6. Project Stub (Required)
• 7. Project Solution (Optional)
• 8. Filling Remaining Problem Details
  • 8.1 Problem Name (Optional)
  • 8.2 Description (Required)
  • 8.3 Difficulty Level (Optional)
  • 8.4 Scoring (Optional)
  • 8.5 Maximum Re-Submissions (Optional)
  • 8.6 Tags (Optional)
  • 8.7 Attachments (Optional)
• 9. Finalizing the Problem
• 10. Understanding the Template Project Structure
  • 10.1 Source Folder (src/)
  • 10.2 Configuration & Environment Files
  • 10.3 Test & Build Configuration Files
  • 10.4 Package & Dependency Files
  • 10.5 TypeScript & Webpack Configurations
• 11. How to write a Test case?

1. Landing on the Dashboard

• When you log in to the DoSelect Platform, you arrive at the Home dashboard.

• From here, you can manage tests and access the Library tab at the top of the page.

• Action: Click on the Library tab to move to the question bank.

2. Navigating to Problem Creation

• Once in the Library, you will see available libraries like DoSelect Questions and My Company Questions.

• At the bottom-right corner, you will find a + (plus) button.

• Action: Click on the + Create a new problem button to start creating your problem.

3. Configuring Basic Problem Details (Required)

• A dialog box titled "Create New Problem" will appear.

• Fill in the following fields:

  • Name: Provide a concise, meaningful title (e.g., "Angular: Currency Converter"). Limit: 45 characters.

  • Problem Type: Select Project Based: FrontEnd.

  • Level: Choose Easy, Medium, or Hard.

  • Framework: Choose Angular(15.0.4, Node 14)

• Action: Click Create to proceed.

4. Setting Up the Project

• Determines how the stub or solution file will be uploaded to the environment for candidate access.

• Ensures the problem setup is correctly provided for execution.

• Allows flexibility in how files are managed and distributed.

You will be directed to the Problem Setup Interface. You can set up the Angular project using one of two methods:

• Upload ZIP (Default & Recommended): A compressed file containing the Angular project stub or solution is to be uploaded directly.

• GitHub Link: A public repository URL should be provided to allow for the cloning of the project.

5. Upload using the ZIP method:

• Use ZIP Upload and download the Project Template to ensure compatibility with the platform environment.

Project Template

• Definition: The project template is a downloadable sample project that provides a basic structure to help get started on creating a project according to the requirements. It ensures environmental compatibility with the platform.

• Purpose:

  • Provides a standardized setup for problem creation.

  • Ensures compatibility with the platform’s execution environment.

• Best Practices:    

  • Use ZIP Upload and download the Project Template to ensure compatibility with the platform environment.

  • After downloading the project template, modify the zip file according to the specified requirements

  • This can be done directly on the platform after uploading the template zip file.

5.1 Things to Remember While Using the Project Template (Angular)

The downloaded projecttemplate.zip includes a sample Angular project and setup guide in the README.md file. Replace the sample implementation with your problem-specific code.

• Modify only the necessary component files inside src/app/components based on your problem requirements.

• If certain files are not relevant (e.g., db.json when no mock API or JSON-server is used), remove them

• Ensure that test cases are added within appropriate directories such as src/app/components(name.component.test.ts). Use Karma (or the configured testing framework) to validate the functionality of Angular components. Refer to the provided test setup for the structure.

• The README.md should be written and aligned with the problem description and test expectations. Avoid any mismatch or ambiguity. There are instructions regarding the environment and IDE in the template README. Modify or remove them only if required.

• Ensure that the relative paths of test files are added correctly to the read_only_files array in configuration.json.

• Any files you want the candidate to see or edit by default (e.g., gadget-card.component.html) should be listed with proper paths under default_open_files.

• Do Not Modify or delete the Platform-required configuration files, such as:

  • angular.json

  • tsconfig.json, tsconfig.app.json, tsconfig.spec.json

  • karma.conf.js, junit.xml

  • webpack.config.js, webpack.prod.config.js

  • Files inside the public/ folder (if present)

• Before zipping the project, exclude generated and unnecessary folders, such as:

  • node_modules/

  • dist/, build/, logs, and cache directories

  • .DS_Store, .angular/cache/, etc.

  • Any files listed in .gitignore

• Ensure the zip structure does not contain a nested parent folder,i.e, Project files should be at the root level of the zip, not inside a subfolder.

6. Project Stub (Required)

• This is the version of the project with key logic removed which will be given for the candidates to fill in the required logic.

• Create the .zip as mentioned above and upload it here. (max 5MB).

• The Open in Editor option allows you to view/edit the stub in the online editor.

• It is recommended to add comments for the candidates where they have to add the code.

6.1 Sanity Check (Required)

• Ensures the stub is valid and will run:

  • ZIP file < 5MB

  • Extracted contents < 20MB

  • Proper structure & valid config format.

  • Test cases fail, and the score is zero. (This will take time as the project is run for evaluation).

• It will run automatically on file upload. If it fails, you can make the changes using the Open in Editor option to modify. Then, rerun the sanity using the play button.

7. Project Solution (Optional)

• Enable this to upload the fully working solution for reference.

• Upload the complete version of your modified project (with logic) for reference.

• Run the Sanity Check to verify everything compiles and works as intended.

• Although this section is optional, it is recommended to upload a solution for accurate validation and reference.

8. Filling Remaining Problem Details

Some details (like name and level) are already set but can be edited here.

8.1 Problem Name (Optional)

• Modify the title if necessary. This is what the candidate will see.
  
  Expected Solving Time (Required)

• Indicate how long the candidate should take (e.g., 60, 90, 120 minutes).

8.2 Description (Required)

This is the problem statement shown to candidates.

8.3 Difficulty Level (Optional)

• Modify if necessary.

8.4 Scoring (Optional)

• Set the score (e.g., 75).

• Penalty does not apply to project-based problems. Leave it at 0.

8.5 Maximum Re-Submissions (Optional)

• Recommended to set to 0 (unlimited submissions).

8.6 Tags (Optional)

• Discovery Tags: Used for filtering/discoverability in your library (e.g., Component Design, Routing)

• Insight Tags: Used for analytics (e.g., State Handling, API Fetching) 

8.7 Attachments (Optional)

• Add relevant or related resources for better problem clarity. This section is completely optional. Examples include:

  • Include a GIF to showcase the expected UI flow.

  • Reference documentation.

9. Finalizing the Problem

Action Buttons

• Save Problem: Saves the current progress of problem creation.

• Lock: Prevents further edits, making the problem non-editable.

• Archive Problem: Marks the problem as inactive, making it unavailable for test assessments.

• Try This Problem: This opens the stub environment for testing. Any changes made will not be reflected in the original project stub file, so it serves as a trial environment.

• Problem Analytics: Provides insights and analytics related to the problem's performance and usage

Note: Ensure all required fields (marked with a red asterisk *) are filled. Otherwise, the problem will remain incomplete and cannot be used in tests.

10. Understanding the Template Project Structure

This structure follows a common pattern for Angular applications, efficiently organizing the source code, configuration files, and test cases.

10.1 Source Folder (src/)

Application Files (src/app/)

• Purpose: The main directory where the core Angular application components are located.

• Requirement: Should contain feature modules, components, and services required for the project.
  
  

Configuration Files

• bootstrap.ts (Not to be changed)

  • Purpose: Used for bootstrapping the Angular application.

  • Requirement: Should correctly configure the root module.
    
    

• index.html (Not to be changed)

  • Purpose: The main HTML file where the Angular app is rendered.

  • Requirement: Must include a root <app-root> tag for rendering Angular components.
    
    

• main.ts (Not to be changed)

  • Purpose: The entry point for Angular applications, responsible for bootstrapping the AppModule.

  • Requirement: Should correctly import and initialize the root module.
    
    

• polyfills.ts (Not to be changed)

  • Purpose: Includes polyfills required for supporting older browsers.

  • Requirement: Must be kept unchanged unless compatibility modifications are needed.
    
    

• styles.scss (To be changed)

  • Purpose: Defines global styles for the application.

  • Requirement: Maintain a clean and structured SCSS layout.
    
    

• test.ts (Not to be changed)

  • Purpose: Configures the test environment for Angular unit tests.

  • Requirement: Should properly import testing modules and configurations.

10.2 Configuration & Environment Files

• angular.json (Not to be changed)

  • Purpose: Stores Angular project configuration settings, including build and test settings.

  • Requirement: Should not be modified unless project setup changes are necessary.
    
    

• configuration.json (To be changed)

  • Purpose: Stores project-related configuration settings.

  • Editable Sections:

    • Default_open_files: Defines which files open automatically when the environment starts.

    • Read-only files: Specifies files that cannot be modified.
      
      

  • Non-Editable Sections: Certain environment-related settings should remain unchanged.
    
    

• db.json (To be changed)

  • Purpose: Contains mock API data when using JSON-server.

  • Requirement: Should be included only if a mock API is required.
    
    

10.3 Test & Build Configuration Files

• karma.conf.js (Not to be changed)

  • Purpose: Configuration file for Karma test runner.

  • Requirement: Should be correctly set up for running unit tests.

10.4 Package & Dependency Files

• package.json (Not to be changed)

  • Purpose: Defines project dependencies, scripts, and metadata.

  • Requirement: Must be correctly configured for smooth execution.
    
    

• package-lock.json (Not to be changed)

  • Purpose: Ensures consistent dependency versions.

  • Requirement: Should not be manually modified.
    
    

• README.md (To be changed)

  • Purpose: Provides project documentation.

  • Requirement: Must be updated with relevant project details.

10.5 TypeScript & Webpack Configurations

• tsconfig.json (Not to be changed)

  • Purpose: Configures TypeScript compiler options.

  • Requirement: Should be properly set up for optimal TypeScript support.
    
    

• tsconfig.app.json (Not to be changed)

  • Purpose: Defines TypeScript settings specific to the application.

  • Requirement: Should be aligned with the project's build needs.
    
    

• tsconfig.spec.json (Not to be changed)

  • Purpose: Configures TypeScript settings for unit tests.

  • Requirement: Should be correctly set up for test execution.
    
    

• tslint.json (Not to be changed)

  • Purpose: Defines linting rules for maintaining code quality.

  • Requirement: Should remain unchanged unless necessary.
    
    

• webpack.config.js (Not to be changed)

  • Purpose: Configures Webpack bundling and optimizations.

  • Requirement: Should be properly set up to optimize performance.
    
    

• webpack.prod.config.js (Not to be changed)

  • Purpose: Webpack configuration for production builds.

  • Requirement: Must be optimized for production performance.

11. How to write a Test case?

This section explains how to write test cases for an Angular component using Karma. Below is an example test case for the MainComponent based on the provided project structure.

Overview

The test file ensures that:

• The MainComponent renders correctly.

• A specific heading is visible on the screen.

• Clicking a button triggers the expected function call.

Imports

import { ComponentFixture, TestBed } from '@angular/core/testing';

import { By } from '@angular/platform-browser';

import { RouterTestingModule } from '@angular/router/testing';

import { MainComponent } from '../../src/app/main/main.component';

• TestBed: Angular testing utility to configure and initialize a testing environment.

• ComponentFixture: Provides access to the component instance and its DOM.

• By: Allows querying DOM elements.

• RouterTestingModule: Mocks Angular Router for testing navigation.

• MainComponent: The component under test.
  
  

Test Suite

describe('MainComponent Test Cases', () => {

it("test 1" () => {
expect() // evaluate the logic of the project
})
})

• describe(): Groups related test cases for MainComponent.

• it(): defines an individual test case, describing what is being tested

• expect(): asserts the expected outcome. If the assertion fails, the test fails.

Test Case 1: Checking the Heading

it('should display the heading on the screen', () => {
    const headingElement = fixture.debugElement.query(By.css('h1')).nativeElement;
    expect(headingElement.textContent).toContain('Hello from DoSelect');
});

Steps:

• Find the <h1> element using By.css().

• Check if its text content includes "Hello from DoSelect".

✅ Ensures that the heading is displayed correctly.

Test Case 2: Button Click Event Handling

it('should call onButtonClick() when button is clicked', () => {
    spyOn(component, 'onButtonClick');

    const button = fixture.debugElement.query(By.css('.learn-more-button')).nativeElement;
    button.click();
    expect(component.onButtonClick).toHaveBeenCalled();
});

Steps:

• spyOn(): Creates a spy to track onButtonClick().

• Find the button using By.css('.learn-more-button').

• Simulate a button click using button.click().

• Assert that onButtonClick() was called.

✅ Ensures that clicking the button triggers the expected function.

Test Case 3: Navigation to Another Page

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

it('should navigate to another-page when button is clicked', () => {
    const router = TestBed.inject(Router);
    spyOn(router, 'navigate');

    const button = fixture.debugElement.query(By.css('.navigate-button')).nativeElement;
    button.click();

    expect(router.navigate).toHaveBeenCalledWith([`${BASE_PATH}another-page`]);
});

Steps:

• Inject the Router service.

• Spy on the navigate() method.

• Find the button and simulate a click.

• Assert that router.navigate() is called with the correct route.

✅ Ensures that clicking the button correctly navigates to /another-page.