Unity AAA Test Pattern

Поділитися
Вставка
  • Опубліковано 26 сер 2024
  • Expect the next video in a couple days.
    Just writing methods that throw exceptions is not enough to get value from your automation. You need a test pattern, like AAA to help organize and
    Please join Patreon / danvioletsagmiller
    Discord Link: / discord
    #unity #unity3d #tutorial #videogamedev #gamedev #architecture

КОМЕНТАРІ • 6

  • @sanatdeveloper
    @sanatdeveloper 3 місяці тому +1

    This video deserves hundreds thousands view!

    • @dvsdev
      @dvsdev  3 місяці тому

      Thank you! I appreciate that.

  • @sadbuttrue666
    @sadbuttrue666 6 місяців тому +1

    Hey, thank you so much for your video(s). You cover things I need to know and get the information to the point without making hour long videos. However, I also have to say that I find the AI generated images completely distracting. A simple screen capture while typing and explaining would be perfectly adequate and more appealing to me. Thank you and have a nice day :)

    • @dvsdev
      @dvsdev  3 місяці тому

      That is a good point. I will keep that in mind. Its also good to get these comments on this one. I'm looking back at this one and finding it useful. It was a different style of editing and takes more effort to prepare. But, it worked out much better in the end as well.

  • @Joseguepardo
    @Joseguepardo Рік тому +2

    Great video! I do have one question though... generally speaking, should you write unit tests for every function of a class in a project?

    • @dvsdev
      @dvsdev  Рік тому +1

      No. If a system is depended on by many other things, then it is more important to test. But in games, many things are really difficult to validate with automation. Physics, Audio, FX, Random, UI, textures, 3D model placement, these are all really difficult to write meaningful test cases for, and they are also much easier to validate by humans. But how the classes communicate, validating the details of the save file, making sure the logic states change at the appropriate times, these are easy to validate in Unit tests and difficult for humans. There is a clear cut off of what works well to automate or not.
      Anything I classify as Architecture or System will typically have 100% code coverage. But the closer it is to a component of a playable game object, the less likely I am to write tests. These change much more often too, so your test cases invalidate themselves very quickly.