fix tool code generation in case of multiline descriptions

[sysradium]

If a tool decorated with @tool contains a multiline comment:

@tool
def ssh_execute_command_with_agent(host: str, port: int, username: str, command: str) -> str:
    """This tool connects to a specified SSH server using the SSH agent for authentication
    and executes a given command on the server. It returns the output of the command
    or any errors encountered during execution.

    Args:
        host: The hostname or IP address of the server.
        port: The SSH port to connect to (default is 22).
        username: The SSH username for authentication.
        command: The command to execute on the server.

    Returns:
        A string containing the command's output or any errors encountered.

    """

It breaks to_dict. It produces something like this:

from smolagents import Tool
            from typing import Any, Optional

            class SimpleTool(Tool):
                name = "ssh_execute_command_with_agent"
                description = This tool connects to a specified SSH server using the SSH agent for authentication
and executes a given command on the server. It returns the output of the command
or any errors encountered during execution.
                inputs = {"host":{"type":"string","description":"The hostname or IP address of the server."},"port":{"type":"integer","description":"The SSH port to connect to (default is 22)."},"username":{"type":"string","description":"The SSH username for authentication."},"command":{"type":"string","description":"The command to execute on the server."}}
                output_type = "string"

    def forward(self, host: str, port: int, username: str, command: str) -> str:

[aymeric-roucher]

Thank you @sysradium !

[albertvillanova]

Thanks! It would be awesome to have a regression test.

[albertvillanova]

Just wondering about an alternative approach.

[sysradium]

@albertvillanova frankly speaking I wanted to refactor tests a bit :) They became a bit too hard to maintain and can be improved (for example by removing side-effects). But maybe I can squeeze in a test for this specific case. No problem

[sysradium]

@aymeric-roucher
Fix a similar problem with description generation when tool is defined as a class. Added tests.

For the future do you have any particular attachment to old-school unittest.TestCase, or as I go I can change then and/or use pytest tests with fixture and parametrization?

[aymeric-roucher]

@albertvillanova about @sysradium's question above: which do you prefer? I see you've introduced many pytest tests, are these preferred?

[sysradium]

I advise to switch to pytest, because you are using pytest runner anyways, but loose the benefits pytest brings, e.g.: https://docs.pytest.org/en/stable/how-to/unittest.html#pytest-features-in-unittest-testcase-subclasses

classes are a nice way to group tests, probably, but instead you can group them using files.

[albertvillanova]

@albertvillanova about @sysradium's question above: which do you prefer? I see you've introduced many pytest tests, are these preferred?

We are using pytest to run our test suite, so better use pytest tests:

smolagents/Makefile

Lines 16 to 18 in 0153e37

	# Run smolagents tests
	test:
	pytest ./tests/

smolagents/.github/workflows/tests.yml

Line 44 in 0153e37

uv run pytest ./tests/test_agents.py

However:

• no need to migrate all tests: unittest tests are supported by pytest
• the use of test classes is also possible in pytest: we align test file names with those of the library under test

[sysradium]

@albertvillanova we just loose a bit of feature if we keep using classes. For example, you can't use tables-tests, or mark tests as deprecated, make them conditioned on python version.

I am not saying we need to go a rewrite everything, but maybe newer test can be just pure functions instead.

I know it is a heated discussion, and quite often people still push for classes, that's why I decided to ask first :) Currently it is a bit of a mix in this project, I want to have some alignment on that.

[albertvillanova]

@sysradium when I say we can use test classes in pytest, I don't mean to use unittest classes, but just regular classes.

And I remember I have already deprecated and skipped tests that were implemented as pytest class methods.

Here the link to Pytest docs about grouping tests in a class: https://docs.pytest.org/en/stable/getting-started.html#group-multiple-tests-in-a-class

[sysradium]

@albertvillanova my bad. Understood. Thank you! :)