[Refactor] Improve efficiency on graph tests and `plot_disjunctive_graph`

[Pabloo22]

Old tests used the .graph attribute. Now, every time we access it, we recompute the nx.DiGraph, which is inefficient. That's why I just refactored the .graph method (to show this inefficiency clearly). The method name is get_networkx_graph().

We need to refactor the tests so that we avoid recomputing the graph property every time. I think that's why many of them are so slow.

[NavidCOMSC]

@Pabloo22 I meant I can take over this issue if it is vacant

[Pabloo22]

Hi @NavidCOMSC, perfect. Your changes will be merged to the branch v2-dev. Thanks for contributing!

Some instructions from Gemini:

For that, you need to fetch the v2-dev branch from the original repository (which we'll call "upstream") and then create your own feature branch from it.

---

The Correct Workflow 🧑‍💻

Here's the step-by-step process. In these commands, we'll use two standard names for remotes:

• origin: This is the default name for your fork (your-username/job_shop_lib).
• upstream: This is the conventional name for the original library repository (pabloo22/job_shop_lib).

1. Configure the "Upstream" Remote

If you haven't already, you need to tell your local clone about the original repository.

First, check your current remotes:

git remote -v

If you only see origin, add the upstream remote for pabloo22/job_shop_lib.

git remote add upstream https://github.com/pabloo22/job_shop_lib.git

2. Fetch All Branches from Upstream

Download all the latest information and branches from the original repository.

git fetch upstream

3. Create a Local Branch Based on v2-dev

Now, create and switch to a new local branch that tracks the v2-dev branch from the upstream repository.

git switch -c v2-dev upstream/v2-dev

4. Create Your Feature Branch ✅

It's best practice to create a new branch for your specific changes instead of working directly on v2-dev. This keeps your work isolated and makes the pull request cleaner.

git switch -c my-new-feature

5. Make Your Changes and Commit

Now you can work on your feature! Make your code changes, then add and commit them as you normally would.

# ...make your code changes...
git add .
git commit -m "[Refactor] Improve efficiency on graph tests and `plot_disjunctive_graph`"

6. Push Your Feature Branch to Your Fork (origin)

Push your new feature branch up to your fork on GitHub. The -u flag sets your local branch to track the remote branch on your fork.

git push -u origin my-new-feature

7. Open a Pull Request 🔃

Go to your fork's page on GitHub. You'll see a prompt to create a pull request from your my-new-feature branch. Click it, and make sure to set the target correctly:

• Base repository: pabloo22/job_shop_lib
• Base branch: v2-dev ⬅️ (This is the crucial part!)
• Head repository: your-username/job_shop_lib
• Compare branch: my-new-feature

Fill in the pull request details and submit it for review.

---

Keeping Your Branch Updated

If the upstream/v2-dev branch gets updated while you're working, you can pull those changes into your feature branch like this:

1. Switch to your local v2-dev branch:
   git switch v2-dev
2. Pull the latest changes from upstream:
   git pull upstream v2-dev
3. Switch back to your feature branch:
   git switch my-new-feature
4. Rebase your changes on top of the updated v2-dev:
   git rebase v2-dev

This workflow keeps your commit history clean and ensures you're working with the most up-to-date version of the code.