I don't think there are any absolute rules on this approach, because it can be pretty case-specific. In my opinion, a general rule on the superior approach to testing does prioritize writing "true" unit tests against independent, isolatable units of code when it is practicable to do so.
I would generally write a separate test for a helper class. However, if the helper exists almost as more of a factoring out of a few methods from the main class and has little to no generality of purpose, it may be code-expensive to test independently (requiring a lot of dependency injection, for example). In that circumstance, the cost/benefit may come down in favor of testing the two code units as a single larger unit and writing only one test class. You might make a case, if you like to argue about the ontology of the code, that those classes aren't independent units at all, and hence ought to be tested together!
Testing multiple code units together does tend to increase the complexity of the testing you need to do in a multiplicative way (this is why good integration tests are hard). If five member functions in
ControllerClass call two static functions in
HelperClass with different kinds of parameters in different orders, that's a lot of potential code paths to evaluate. Unit testing can help by demonstrating that each unit (in this case, a method) of code works as expected prior to attempting that kind of integration test.
On balance, if the helper class is something like a static utility class or a helper that's used in various places throughout your code base, I would say it definitely needs an independent test. If it's an inner class of a controller or in some other way very tightly coupled to a main class, I see a case for writing only one test class for the pair.