Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stats matchers #851

Closed
sksamuel opened this issue Jun 21, 2019 · 7 comments
Closed

Stats matchers #851

sksamuel opened this issue Jun 21, 2019 · 7 comments
Labels
assertions 🔍 Related to the assertion mechanisms within the testing framework. enhancement ✨ Suggestions for adding new features or improving existing ones. good-first-issue 👶 Suitable for newcomers looking to contribute to the project.
Milestone

Comments

@sksamuel
Copy link
Member

list.shouldHaveMean(123.45)
list.shouldHaveStandardDeviation(55.123)
list.shouldHaveVariance(9.4)

@sksamuel sksamuel added enhancement ✨ Suggestions for adding new features or improving existing ones. good-first-issue 👶 Suitable for newcomers looking to contribute to the project. labels Jun 21, 2019
@sksamuel sksamuel added this to the 3.5 milestone Jun 21, 2019
@alladywek
Copy link
Contributor

alladywek commented Jul 20, 2019

I have a few moments regarding details of implementation:

  1. what number types do you want to support?
  2. what do you think about using BigDecimal as expected value? It gives more precision result and easier calculations
  3. It would be great to have second optional parameter (precision: Int) for these methods where user can specify amount of digits after decimal point:
    list.shouldHaveMean(BigDecimal("0.667"), 3)
    list.shouldHaveMean(BigDecimal("0.67"), 2)

Problem with Double is that you can specify only 16-17 digits and other will be lost

fun main() {
  val double = 123456789.01234567890123456789
  println(double)                       //1.2345678901234567E8
  println(BigDecimal(double))           //123456789.01234567165374755859375
  println(BigDecimal(double.toString()))//123456789.01234567
}

@sksamuel
Copy link
Member Author

I think BigDecimal is good yes, but I think we should support doubles too. Obviously there can be precision errors, but we regularly test doubles everywhere else, so I think having both options is the best way. Perhaps with your precision parameter idea.

@alladywek
Copy link
Contributor

alladywek commented Jul 26, 2019

yep, I agree that both variants it is good idea, so lets summarize which methods we expect (for methods without explicit precision we can set up precision=5 by default):

Collection<Double>.shouldHaveMean(mean: Double, precision: Int)
Collection<Double>.shouldHaveMean(mean: BigDecimal, precision: Int)
Collection<Double>.shouldHaveMean(mean: Double) 
Collection<Double>.shouldHaveMean(mean: BigDecimal)
DoubleArray.shouldHaveMean(mean: Double, precision: Int)
DoubleArray.shouldHaveMean(mean: BigDecimal, precision: Int)
DoubleArray.shouldHaveMean(mean: Double)
DoubleArray.shouldHaveMean(mean: BigDecimal)

Collection<Double>.shouldHaveStandardDeviation(mean: Double, precision: Int)
Collection<Double>.shouldHaveStandardDeviation(mean: BigDecimal, precision: Int)
Collection<Double>.shouldHaveStandardDeviation(mean: Double)
Collection<Double>.shouldHaveStandardDeviation(mean: BigDecimal)
DoubleArray.shouldHaveStandardDeviation(mean: Double, precision: Int)
DoubleArray.shouldHaveStandardDeviation(mean: BigDecimal, precision: Int)
DoubleArray.shouldHaveStandardDeviation(mean: Double)
DoubleArray.shouldHaveStandardDeviation(mean: BigDecimal)

Collection<Double>.shouldHaveVariance(mean: Double, precision: Int)
Collection<Double>.shouldHaveVariance(mean: BigDecimal, precision: Int)
Collection<Double>.shouldHaveVariance(mean: Double)
Collection<Double>.shouldHaveVariance(mean: BigDecimal)
DoubleArray.shouldHaveVariance(mean: Double, precision: Int)
DoubleArray.shouldHaveVariance(mean: BigDecimal, precision: Int)
DoubleArray.shouldHaveVariance(mean: Double)
DoubleArray.shouldHaveVariance(mean: BigDecimal)

... the same for Int.

support for Long, Float, BigDecimal types could be added in future by requirements.
what do you think?

@sksamuel
Copy link
Member Author

@alladywek are you still planning to work on this ?

@sksamuel sksamuel modified the milestones: 3.5, 4.0 Sep 4, 2019
@sksamuel sksamuel added the assertions 🔍 Related to the assertion mechanisms within the testing framework. label Sep 4, 2019
@alladywek
Copy link
Contributor

Hi @sksamuel , sorry that I am late to reply, but if it is still actual I can pick up this and finish by end of next week.

@sksamuel
Copy link
Member Author

sksamuel commented Sep 4, 2019 via email

alladywek pushed a commit to alladywek/kotlintest that referenced this issue Sep 13, 2019
sksamuel pushed a commit that referenced this issue Sep 14, 2019
alladywek pushed a commit to alladywek/kotlintest that referenced this issue Sep 14, 2019
alladywek pushed a commit to alladywek/kotlintest that referenced this issue Sep 14, 2019
alladywek pushed a commit to alladywek/kotlintest that referenced this issue Sep 14, 2019
sksamuel pushed a commit that referenced this issue Sep 14, 2019
* #851 add docs

* #851 remove docs from matchers.md
alladywek pushed a commit to alladywek/kotlintest that referenced this issue Sep 14, 2019
@sksamuel sksamuel mentioned this issue Nov 25, 2019
88 tasks
@LeoColman
Copy link
Member

Closed as per #989

sksamuel added a commit that referenced this issue Feb 16, 2020
Co-authored-by: Stephen Samuel <sam@sksamuel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assertions 🔍 Related to the assertion mechanisms within the testing framework. enhancement ✨ Suggestions for adding new features or improving existing ones. good-first-issue 👶 Suitable for newcomers looking to contribute to the project.
Projects
None yet
Development

No branches or pull requests

3 participants