TheHarpyEagle

  • 0 Posts
  • 26 Comments
Joined 1 year ago
cake
Cake day: August 18th, 2023

help-circle


  • I feel like there’s a specific peak between total technical ignorance and a weary understanding of how fickle technology can be. On this peak is the height of arrogance, where you believe you’ve really got everything figured out. Part of learning is understanding that, yes, sometimes you really did just forget to plug the modem in.











  • I had such high hopes for HBO Max as a bastion for animation before they got completely fucked. They nuked Summer Camp Island (a very wholesome, charming, and slightly weird show) right before its final season came out, delaying the premiere more than a year and with zero notice to its creator, Julia Pott. Pott implied as legally as she could that the season would get out there one way or another, so either someone at CN has a heart or her threat worked.

    And to this day they deny that Summer Camp Island, OK KO, Infinity Train (one of CN’s top performing shows!), and others even existed, while cutting funding for even more shows. I’m still devastated, we had a beautiful revival in the 2010s, but now there’s barely anything new on at all. So many up and coming creators utterly shafted no matter what network they work with.

    All we really have left is Prime and Netflix, and god knows those aren’t reliable. What a mess…







  • For unit tests, you should know the input and expected output from the start. Really responsible devs write the unit tests first, because you should know what you’re going to put in and what you’ll get out before you start writing anything. If you find yourself making the same mistakes in your tests as you do your code, you might be trying to do too much logic in the test itself. Consider moving that logic to its own testable class, or doing a one-time generation of a static set of input/output values to test instead of making them on the fly.

    How granular your tests should be is a matter of constant debate, but generally I believe that different file/class = different test. If I have utility method B that’s called in method A, I generally test A in a way that ensures the function of B is done correctly instead of writing two different tests. If A relies on a method from another class, that gets mocked out and tested separately. If B’s code is suitably complex to warrant an individual test, I’d consider moving to to its own class.

    If you have a super simple method (e.g. an API endpoint method that only fetches data from another class), or something that talks with an external resource (filesystem, database, API, etc.) it’s probably not worth writing a unit test for. Just make sure it’s covered in an integration test.

    Perhaps most importantly, if you’re having a lot of trouble testing your code, think about if it’s the tests or the code that is the problem. Are your classes too tightly coupled? Are your external access methods trying to perform complex logic with fetched data? Are you doing too much work in a single function? Look into some antipatterns for the language/framework you’re using and make sure you’re not falling into any pitfalls. Don’t make your tests contort to fit your code, make your code easy to test.

    If ever you feel lost, remember the words of the great Testivus.