What tests are expected when submitting a pull request?

[Suhebdevtechnosys]

Select Topic Area

Question

Body

Before you send your code changes for review (a pull request), what kinds of tests should you run to make sure your changes don’t break anything?

[girishlade111]

Running the right tests locally before you create a pull request (PR) is a key part of being a good teammate—it saves everyone time and helps keep the main codebase stable.

You should think of it as a pyramid, starting with the fastest, most specific tests and moving to the most comprehensive ones.

The Pre-PR Testing Checklist

Here are the kinds of tests you should run locally, in order of execution:

1. Linting and Static Analysis
   What it is: This isn't a test that runs your code, but rather a tool that reads your code to catch syntax errors, style issues, and potential bugs before you even run it.

Why run it: It's the fastest check you can do. It keeps the codebase clean, consistent, and free of silly mistakes.

Examples: Running eslint . for a JavaScript project or flake8 / black for Python.

2. Unit Tests
   What it is: These are small, fast tests that check individual "units" of your code (like a single function or component) in isolation.

Why run it: This is your most important safety net. It confirms that the specific pieces of code you wrote work as you expect. You should run the entire test suite for the project, not just the tests for your new code, to make sure your changes didn't accidentally break something unrelated.

Examples: Running npm test or pytest.

3. Integration Tests
   What it is: These tests check how different parts of your application work together. For example, does your code correctly fetch data from the database? Does an API endpoint successfully call another service?

Why run it: They catch errors that unit tests miss, specifically in the "gaps" between different components.

Examples: A test that writes a record to a test database and then tries to read it back.

4. End-to-End (E2E) Tests
   What it is: These are large-scale tests that simulate a real user's workflow from start to finish. For a website, an E2E test might automate a browser to log in, add an item to a cart, and complete the checkout process.

Why run it: This is the ultimate confirmation that the overall user experience is still working. These tests are slow, so you often only need to run the ones relevant to the feature you changed.

Examples: Running tests with frameworks like Cypress or Selenium.

The Final, Crucial Step

Before you push your code and create the PR, do this:

Pull the latest changes from the main branch:
git pull origin main (or develop, whichever your target branch is).

Re-run your tests one last time.

This step is critical because it ensures your changes work with the latest code from your teammates, preventing the classic "it works on my machine!" problem.

By following this process, you can be confident that your pull request is in great shape for review.