feat e2e tests to verify for tasks tab functionality

[RavinduWeerakoon]

E2E tests to verify the Tasks tab functionality on the DAG detail page
Add 'dag-tasks.spec.ts', which verifies

• Navigate to a DAG's Tasks tab
• Verify tasks list displays with columns: task name, operator, trigger rule, last instance
• Search tasks by name
• Filter tasks by operator dropdown
• Filter tasks by trigger rule dropdown
• Filter tasks by retry values
• Filter tasks by mapped status
• Verify that clicking a task shows task details

closes: #59543

Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[RavinduWeerakoon]

I tried to make use of data-testid attributes as much as I can, and for places where I can't I have used other matching methods like based on text content etc.

[vatsrahul1001]

Thanks for the PR @RavinduWeerakoon I will review soon.

[vatsrahul1001]

@RavinduWeerakoon Thanks for the PR! Good structure and use of data-testid. Here's feedback:

1. Add DAG trigger in beforeAll - Need to run the DAG to test "Last Instance" column with actual status data

2. Add test for Last Instance column - Verify timestamp and status badge are displayed correctly

3. Test status colors - Verify success (green) and skip status display correctly (example_bash_operator has skipped tasks)

4. Use config for DAG ID - Replace hardcoded "example_bash_operator" with testConfig.testDag.id

5. Test names - Use "verify" prefix: verify tasks tab displays list, verify search filters tasks, etc.

I have also added these in review comments as well please check those as well
Let me know if you have questions!

[vatsrahul1001]

@RavinduWeerakoon can you resolve conflicts?

[RavinduWeerakoon]

Hi @vatsrahul1001, thanks for the comments. I’ve resolved some of the issues.
I still have some doubts about creating the test scenario for the filter. For these different aspects (such as trigger rules) to be available, do we need to define a DAG at runtime with the required behavior and then test how the filters work

[vatsrahul1001]

Hi @vatsrahul1001, thanks for the comments. I’ve resolved some of the issues.
I still have some doubts about creating the test scenario for the filter. For these different aspects (such as trigger rules) to be available, do we need to define a DAG at runtime with the required behavior and then test how the filters work

For this PR, I suggest
Keep filter tests that work with example_bash_operator (operator, search), remove or skip filters that don't have meaningful data (mapped, multiple trigger rules). You can implement more comprehensive tests in a follow-up PR with appropriate DAGs

[vatsrahul1001]

@RavinduWeerakoon you also needs to rebase

[RavinduWeerakoon]

Hi @vatsrahul1001, thanks for the comments. I’ve resolved some of the issues.
I still have some doubts about creating the test scenario for the filter. For these different aspects (such as trigger rules) to be available, do we need to define a DAG at runtime with the required behavior and then test how the filters work

For this PR, I suggest Keep filter tests that work with example_bash_operator (operator, search), remove or skip filters that don't have meaningful data (mapped, multiple trigger rules). You can implement more comprehensive tests in a follow-up PR with appropriate DAGs

Ok, I will remove the meaningless filter tests then

[pierrejeambrun]

@RavinduWeerakoon Thanks for your work on this PR.

+1 for not making this overly complex by testing every single filters. If the default test dag do not cover those just remove them.

Can you also address the remaining comments, most of them are low effort and this should make this mergeable :)

[RavinduWeerakoon]

Hi @vatsrahul1001, Any other things that I have to do to make this mergable

[vatsrahul1001]

Hi @vatsrahul1001, Any other things that I have to do to make this mergable

Merged. Great work @RavinduWeerakoon !