FIX: Faulty PEFT tests
Author: BenjaminBossan
Pull request: yes

Two [PEFT tests are actually failing](https://github.com/huggingface/transformers/actions/runs/14632303734/job/41057310419#step:13:241):

- `tests/peft_integration/test_peft_integration.py::PeftIntegrationTester::test_delete_adapter`
- `tests/peft_integration/test_peft_integration.py::PeftIntegrationTester::test_peft_pipeline_no_warning`

This must have been going on for some time but was apparently never noticed. The cause is that the tests themselves are faulty, the PEFT integration is correct in these cases.

## `test_delete_adapter`

The first faulty test was introduced by #34650. AFAICT, it should never have passed in the first place, the PEFT integration logic was not changed in the meantime. At this point, the logs for the PR CI are gone, so I'm not sure if the test passed back then or not.

## `test_peft_pipeline_no_warning`

This test was introduced in #36783 and IMO should also never have passed, as the [`self.assertNoLogs` context manager](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertNoLogs) only returns `None`, thus the assert should never have worked (mea culpa for suggesting this code snippet). Here too, the CI logs are deleted by now, so I can't check if the test already failed back then.

## Note

Overall, I'm a bit concerned that those tests apparently never passed but the PRs were still merged. Also, it would be great if the PEFT maintainers could be alerted when the transformers PEFT tests fail. However, I could not find where the corresponding CI is defined.

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [x] Did you write any new necessary tests?

Comments:
Hi 👋, thank you for opening this pull request! The pull request is converted to draft by default. The CI will be paused while the PR is in draft mode. When it is ready for review, please click the `Ready for review` button (at the bottom of the PR page). This will assign reviewers and trigger CI.

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_37757). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

cc @ydshieh

Just providing some side notes/details. Overall, it seems like it should not be slow runs (anymore) and should be updated, see 
https://github.com/huggingface/transformers/blob/555693fbfaedae26231f282a796e77629ed1ca76/tests/peft_integration/test_peft_integration.py#L56-L57

This is why the normal/usual CI never picked it up, and it seemed like they were passing even though they weren't (because they were skipped). Also checked whether the initial test version (by using the version of that commit) worked for `delete_adapter` and it doesn't look like it.

Thanks @vasqu for investigating. Indeed, the `@slow` decorator is most likely the culprit. I think it would make sense to remove it from the class and only decorate individual functions that are actually slow. However, I don't know what would be considered slow in transformers, so I leave this decision up to @ydshieh.

> However, I don't know what would be considered slow in transformers, so I leave this decision up to @ydshieh.

Anything using a **real** checkpoint on the Hub should be slow, unless that repository is created for testing purpose with small model weights.

Any test > 60 seconds should be slow, but we should try to keep any test as fast as possible.

Maybe running the peft test on cpu machine with `--durations=100` to get an idea if you want.

In any case, as long as it is running on daily scheduled CI, it's fine. We just need remember to have a look on the report :-)

You have merge permission right? If not let me know