-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Creating a unit test package #41
Comments
Why do you want the tests to be included in the visual studio solution but not the unity project? I used to use Extras for this kind of thing, but these days I just have a separate unity project that contains all the test packages. I agree with you that it's annoying to be forced to include the tests for each package in every project. Then the test packages just depend on the packages they are testing. This is also nice because I have just one project where I need to run all the tests on our build server. |
I don't usually include test files in whatever source I'm building. So in the case of Unity, it didn't feel right including test files in my Unity project and including them in compilation of the game build. By having the project in VS, I can just run my test suite with a keypress. I only write tests for my non-Unity pieces though, so I should consider the example you gave of using a separate Unity project for tests. Perhaps I need to explore more about running my tests within Unity. Personally, I like to keep my tests as close to the source as possible, so that was where my inclination to have parallel test packages. When developing my "Auth" package, I would have a parallel "Auth.Tests" package that I can run after any change to the "Auth" package. Doing it as a VS project seemed like a good way to keep these tests close to the source, while doing the Extras or separate Unity project seem like a bit more of a roundabout way of running the tests. In any case, this issue can be closed if you feel testability is not an issue, or could be used to further brainstorm. In the meantime, I will try my hand at using Extras or the separate Unity project. |
Ah ok I see what you mean about having them within Visual Studio only so you can directly run them there. The problem is, I'm not really sure how that would be implemented even if we wanted to go that route (that is, of only including certain packges in VS only). Right now all the source files in the VS solution use the path underneath the UnityProjects directory. So if we wanted to include some source files in the VS solution but not inside unity, we'd have to reference the files directly using their path underneath UnityPackages. Which is doable I suppose. Honestly though, I'm not sure the extra implementation complexity is worth it. If it's just unit tests, then I assume they are underneath an Editor folder, right? In that case, they won't have any affect on the final builds, other than compile time. But for compile time, you can at least optimize that by dragging packages between assets and plugin directories in the projeny gui. So it kinda sounds to me like using Extras is the best solution for you I'll leave this item open as something to think about |
I am not sure if this is already supported. If it is, it isn't clear the proper way to do it. The documentation on 'Extras' alludes to it.
It would be useful to have a way to define a unit test csproj for a package. However, I don't really want my unit tests to end up in the final Unity project, which I believe the 'Extras' approach would do.
Perhaps, similar to 'Dependencies', I could declare a 'TestDependencies' in my ProjenyPackage.yaml. This would reference another package that contains all of my unit tests. Projeny could handle generating the solution, and creating the dependency reference from the test package to the source package. But it would not symlink the test package into my Unity project.
The text was updated successfully, but these errors were encountered: