I want to make running the tests easier. To achieve this I want to provide the secrets used in the tests inside my project. I create the 'fullchain.pem', 'privkey.pem' and 'dhparams.pem' with this commands:
openssl genrsa > privkey.pem
openssl req -new -x509 -key privkey.pem > fullchain.pem
openssl dhparam -out dhparams.pem 4096
Is it safe to publish this files if I run the tests in a local network?
It's hard to say for sure without knowing the architecture of your system, however, in general if something is bad practice in production, it should be bad practice in development (with the exception of being able to turn on dev tools).
So this is where the architecture of the system comes into play. For a server side system, your PEM should always remain local and only the public key ever leave the server. If you have a need to get the PEM on the client side, there is something fundamentally wrong with your system you need to fix.
Your keys are also only important when they are known. So, if you do something unsafe with them in testing, but create new ones for production, there isn't an issue (assuming you are using dummy data in testing).
As for your question about adding the files once you publish your system, you should be placing the files on your server in a non-publicly available area. Typically you'll have something like a structure like this:
var/www/{publicly available content}
you should then be putting your keys somewhere like this:
var/.ssh/{private keys}
The files on your server can access them, but not the public.
Attackers can obvious get access to your tests secrets when you make them public. But then, how much of an impact can they make with those secrets? It's hard to say without knowing more about your system and use cases.
Exposing secrets publicly is always considered a bad practice, but it's not always harmful, as the system might also have other security measures. For example, one mights have the secrets to an internal system, but they cannot do anything before they can pass throught the firewall. Another example is when the system is just a toy system without any value to protect, the owner might prioritize simplicity over security.
Back to your specific case, if you think the simplicity is worth and your system does not hold any crucial value/information, you can continue using this way. If not, there are some solutions that I can suggest for the 2 problems that you mentioned in the comments (Portability and Maintainability):
If you prefer generating secrets once: Use a secret management system, there are many choices out there. Personally, I use chezmoi and bitwarden (I then just need to refer the secret in my public git repo, the actual secrets are stored in bitwarden).
If you prefer regenerate secrets every time you run the tests (this is the more idiomatic way): You should rely on other tools to provide you the Portibility and Maintainability. Traditionally, people would include several static binary and/or script versions for each OS version that they care. A better way these day is to use docker image with sha hash so you can guarantee that it will run anywhere and will never change.