So this is how you guys seem to be doing things currently:
- Write feature
- Half-*** test it
- Release it without really knowing if it works or not
- Lose sleep(?)
But harken! There is a better way!
- Select feature you are about to add/improve/repair
- Write unit test for feature
- Add functionality to feature that passes unit test
- Add unit test to automated test list
- One day in future see that unit test is failing. Don’t release broken product.
- Release GOOD product.
This is how come your **** doesn’t work and why for you released three showstopping bugs for iOS in 4.19 that you still don’t know about and haven’t commented on.
I want to help you because bad developer culture is nobody’s fault. It just creeps in. But it is your fault when someone brings it up and you don’t fix it.
So let’s go over some examples. Right now you can package and launch a brand new iOS project but you can’t package and launch existing projects from 4.18. I honestly don’t know what the regression is, but I bet a unit test would help us figure it out! Here’s what you do:
- Go back to unit test you already wrote (good developer, you get a cookie)
- Expand test with new test criteria and validate that it now fails as per user report
- Fix feature
- Test passes
- Forum sings your praise and you sleep like a baby
Your unit test codebase should be as large if not larger than your actual codebase. Is that more work? Well, yeah, at the beginning. But once your framework grows colossal like UE’s is it starts saving you hours upon hours of developer time and frustration. It also requires little to no maintenance.
And the best part is it makes testing your feature changes a lot simpler because you sit down, adjust the test for the new output, adjust the feature, then run the test. If the test fails you don’t even bother loading the test build, you just fix it until it passes and THEN you perform user testing.
Unit tests even make you want to structure your methods properly as little bits of commandlets rather than monolithic functions that do too many things like what UE is full of right now.
So what’d we miss that we should write unit tests for today?
- Hot fix for metal debug library included in shipping build did not do what it was intended to do. At all. This was such a big deal that you should write a test for it even if it’s working in 4.19.
- Fix for UE packaging the wrong icon in iOS IPAs still has the wrong icon being packaged in iOS IPAs. This seems like a hard thing to miss unless you’re adhering to step 2: half-*** test it.
- iOS and Android Online Subsystems still don’t work in either fresh projects or old ones. There’s probably more to this but let’s find out by writing a unit test!
You know what’s super exciting? You can release your unit tests! Then when a user has a problem they can run the unit tests and tell you what the result was! Wowee!
Hey, your users might even update your unit test for you so that it catches the edge case and submit it as a pull request! And they’ll do it because you made it easy by writing the unit test in the first place! And you can validate that a pull request is any good by checking to see if they created or updated a unit test! Make them do it or they don’t get in! That’s called a virtuous circle!