Added basic weakpoint unittest

[StStep]

Summary

None

Purpose of change

Add a unit test for helping with #51305

Describe the solution

Added a unit test that works of statistical damage rates

Describe alternatives you've considered

Splitting into projectile testing and melee testing. Including project code had it go through the crit/good-hit/glance code which made doing damage aver checks hard.

Testing

Additional context

[StStep]

This is my first time making a unit test for this project, and I'm not sure how to best handle checking this. Damage average makes since to me, but it looks like it can vary outside of the current epsilon, so bad random failures. I suppose I could make the func accept percent hit of weakpoints instead of average damage and then count the number of weakpoint hits and go from there? I do want to try and check the armor changes for weakpoints are being used though.

Instead of having the programmer do the math, perhaps the test could directly parse the weakpoints json for the monster and calculate what it should be?

[wapcaplet]

It is always nice to see more unit tests. This looks good so far. One thing I would suggest is to make your damage_monster function return the float for total damage done, then do the CHECK parts inside the TEST_CASE (instead of inside the called function), something like this:

CHECK( damage_monster( ... ) == Approx( 18.75f ).epsilon( 0.15f ) );

This is mainly a style issue, but I've found tests to be generally more readable when their expectations are structured in this way. This would also allow you a finer-grained control over the epsilon for each case.

I see you already know the importance of Approx to deal with the potential randomness of damage calculation. I am afraid I don't have specific feedback on your questions for making it more predictable, but we do have some existing tests for weapon average damage per second in tests/effective_dps_test.cpp you might draw ideas from, if you have not already.

[wapcaplet]

At a glance, the latest changes look good to me. I like the idea of summarizing the results in a report structure; it helps with readability in the main test.

The continuous integration test that’s failing (basic build and test / GCC) is a field test I’ve seen false alarms from before, so you shouldn’t have to worry about that, in case you were wondering.