Search Unity

ScriptableObjects, Resources folder and Tests conflict

Discussion in 'Package Manager' started by bdominguezvw, Jan 7, 2020.

  1. bdominguezvw

    bdominguezvw

    Joined:
    Dec 4, 2013
    Posts:
    96
    My package layout regarding tests:

    Code (csharp):
    1.  
    2. <root>
    3.   ├── Tests
    4.   │   └── Runtime
    5.   │        └── Resources
    6.   │            └── MyScriptableObject.asset
    7.   │        ├── MyPackage.Tests.asmdef
    8.   │        ├── MyScriptableObjectMonoBehaviourScript.cs
    9.   │        └── MyTests.cs
    10.  
    MyScriptableObject.asset contains "MyScriptableObjectMonoBehaviourScript.cs"

    My problem is that when I publish my project it includes that "Resources" folder incorrectly and because the script attached to the ScriptableObject doesn't exists, it triggers that error in the console.

     
    Last edited: Jan 7, 2020
  2. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,657
    You can't call the folder 'Resources.' That's a special folder name in a Unity project. Something like 'TestResources' should work OK.
     
  3. pahe4retro

    pahe4retro

    Joined:
    Aug 13, 2019
    Posts:
    33
    If you need to load assets from your package, you should check the entry in the manual: https://docs.unity3d.com/Manual/upm-assets.html

    Hope that helps.
     
  4. bdovaz

    bdovaz

    Joined:
    Dec 10, 2011
    Posts:
    1,051
    But that's different.

    There are two cases:

    1. You want to use real Resources API (in order to run player tests in a real build) so you need to call it "Resources" but you get the problem that it will get included in a real player build and it should not as it's inside the tests folder. There should be at least an API to filter resources that gets included in the final build because it's not the same to do a build to execute runtime tests or to build a real project that includes a Packages with this tests.

    2. You want to only run tests on editor so in that case you can call the folder as you want and load it with C# File API.
     
  5. bdovaz

    bdovaz

    Joined:
    Dec 10, 2011
    Posts:
    1,051
    As I said in my previous post, how do you resolve the first case? That's not explained in that page.
     
  6. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,657
    If you want to dynamically load a resource during an Editor test, use AssetDatabase.LoadAssetAtPath(). That will let you load an asset from any path, without needing any special folder names.

    For playmode tests - we don't have a great automatic solution today. I would probably try and build the resources into an AssetBundle that you can include/exclude from the StreamingAssets folder.
     
  7. bdovaz

    bdovaz

    Joined:
    Dec 10, 2011
    Posts:
    1,051
    I said PLAYER test, in test runner you have an option to run tests doing a special test build.
     
  8. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,657
    You might be able to use the ITestPlayerBuildModifier attribute to solve this. You can customise which scenes are included, so you could add a scene which contains a MonoBehaviour that references your test resources.
     
  9. bdovaz

    bdovaz

    Joined:
    Dec 10, 2011
    Posts:
    1,051
    But if I specifically want to use Resources API because I want to test a method that uses an asset loaded from Resources folder... Your approach it's entirely different.
     
  10. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,657
    In that case what I'd do is have the resources in a Resources folder, and use an IPreprocessBuildWithReport to move/rename the folder prior to making a normal build, then IPostprocessBuildWithReport to move it back again.

    But really, this kind of thing is why we recommend against using the Resources folder.
     
    pahe4retro likes this.