Fix SeekBarWireframeMapper flaky test

[ambushwork]

What does this PR do?

The main cause is that fakeProgress has random value such as 0.00001, which loses some precision when convert to Int and convert back to float, so fakeProgressInt from 0~100 limit only two decimal .

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Make sure you discussed the feature or bugfix with the maintaining team in an Issue
• Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.28%. Comparing base (7ebe827) to head (2a03b54).
Report is 6 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #2308      +/-   ##
===========================================
- Coverage    70.32%   70.28%   -0.05%     
===========================================
  Files          736      736              
  Lines        27466    27466              
  Branches      4607     4607              
===========================================
- Hits         19315    19302      -13     
+ Misses        6871     6868       -3     
- Partials      1280     1296      +16     

see 28 files with indirect coverage changes

[0xnm]

Thanks for the explanation @ambushwork, but I still feel I'm not getting it, especially this part:

which loses some precision when convert to Int and convert back to float

Can you give a concrete example where it leads to the test failure?

[ambushwork]

@0xnm yes, so if the test runs under previous code, fakeProgress can generate a random value such as 0.0002096 as a percentage from 0f to 1f.
and let's imagine the fakeMinValue is 0 and fakeMaxValue is 22631, so with the mock condition:

 whenever(mockView.progress) doReturn ((fakeMaxValue - fakeMinValue) * fakeProgress).toInt() + fakeMinValue

mockView.progress will return 4. This is the abosulote value from fakeMinValue to fakeMaxValue.

In the function map that we want to test, it will normalise the absolute value back to percentage value, by using

view.progress.toFloat()/(maxValue-minValue)

which returns 0.0001767.

so we can see there is already a difference between 0.0002096 and 0.0001767. and finally we will use this value to calculate the active track width of the seek bar, which should be multiplied by the width of the whole track. Due to this, the difference of the two value is amplified.

[0xnm]

@ambushwork I have the feeling that even with this change test may be flaky, just the probability will be much lower, but let's see.

[ambushwork]

@ambushwork I have the feeling that even with this change test may be flaky, just the probability will be much lower, but let's see.

yes, that's correct, with original code the chance of failure is kind like 1 in 2000, with the fix I think it can be reduced about 100 times, which I think it's acceptable.