Mod/plugin author check in.

[Tyrsson]

As mod/plugin (or app) author are you using phpunit in your CI/CD pipelines? If not; why not?

I realize this question cuts across more than your local. Many authors may use it locally, but what about those authors that have users that contribute (@vbgamer45, @Arantor come to mind) and need a CI/CD pipeline that enforces a standard. Not only for unit testing, but for formatting as well.

What are your targets for test coverage?

Does your coverage targets depend on the platform you are developing for, or, do you have personal targets that you impose on your code before it can be released?

 

[vbgamer45]

I am not mainly since not a OOP developer at least not from starting from zero. Haven't ever done any unit testing. I understand the value when doing OOP. My goal is mainly does it minimally work if so great, then add on to it as time goes on.I had a baste taste from the PHPUnit when they a remote exploit hole that allowed any code to execute, was from a composer package that I didn't realize. Lesson learned to deny access to vendor directory/keep it in a private folder.

 

[Tyrsson]

Lesson learned to deny access to vendor directory/keep it in a private folder

Yea, it should never be in the doc root.

 

[Tyrsson]

My goal is mainly does it minimally work if so great

I see no reason why it would not work. I've used both and honestly I think Psalm is the better of the two. Seems the docs are better and it's overall easier to setup and use. Especially when introducing it into a project that is already established. You can set it up. Create a baseline which keeps your new code in conformance and you can then, when you have time or the desire to do so, run it and ignore the baseline to find issues from before the baseline was created. Once fixed, just reset the baseline.

 

[Tyrsson]

Just finished the psalm cleanup and here's the result:

Psalm was able to infer types for 99.3322% of the codebase

I think that will do for a baseline

 

[live627]

As mod/plugin (or app) author are you using phpunit in your CI/CD pipelines?

Yes, but only on my larger mods, mainly to test crucial features. Example: only test button insertion and placement in my menu mod.

What are your targets for test coverage?

Nope. Coverage targets be silly, dawg. That menu mod I alluded to earlier has around 5% coverage. I don't care. Why waste time writing tests to reach a magical number only for tehem to be brittle and perhaps wind up getting removed in the future because it fails? (Caveat: A parser really should be thoroughly tested)

I am not mainly since not a OOP developer

don't need code built in that paradigm to write unit tests for it.

 

[Tyrsson]

To each their own.

 

[Tyrsson]

only for tehem to be brittle and perhaps wind up getting removed in the future because it fails?

The point, I would say the entire point, is for them to never be removed because they fail. Now, that's silly. The better approach would be to get them to passing, or refactor the code so that it is more testable. It's not just about passing, failing and coverage. It's about maintainable code and reducing developer overhead. The better your coverage in terms of Unit/Integration testing/Static Analysis the better the script engine knows the context of your code. I can't begin to fathom, from a developers perspective, how that could possibly be silly in any stretch of the imagination, or practice for that matter.

If your Unit/Integration test suite starts to become brittle, after it served you well, would that not indicate that you are making changes to the code that should be deeply analyzed before moving forward? I mean it's just a thought....