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

Add mature test suites #9

Open
montanaflynn opened this issue Oct 16, 2015 · 8 comments
Open

Add mature test suites #9

montanaflynn opened this issue Oct 16, 2015 · 8 comments

Comments

@montanaflynn
Copy link
Owner

Even though I've spent a lot of time writing tests for stats I think it could benefit from incorporating other more mature test suites from other statistics tools as well. For instance here's a NIST test suite used by Gnu gsl which could be ported to Go and added as a test for stats.

I'm sure there are other test suites as well, let me know if you have suggestions or want to help with this!

@montanaflynn
Copy link
Owner Author

Here's the NIST suite + added autocorrelation function: https://github.com/montanaflynn/stats/tree/nist_test_suite

@LuizClaudioSantos
Copy link

I am not sure about what did you mean here, it is about to rewrite NIST test suite in GO? and then replace all tests?

@montanaflynn
Copy link
Owner Author

montanaflynn commented Jan 13, 2021

@LuizClaudioSantos I think the idea was that the more tests the better, so instead of replacing tests it would be adding more tests from mature projects, such as NIST and others that we could find. Actually I already added some of NIST test suite:

https://github.com/montanaflynn/stats/blob/master/nist_test.go

@tzzed
Copy link
Contributor

tzzed commented Apr 15, 2021

What do you think about using https://pkg.go.dev/github.com/stretchr/testify.

@montanaflynn
Copy link
Owner Author

@tzzed I don't see the need for that, we're not using http or mocks so testing is pretty straight forward and easy with the standard library testing.

@tzzed
Copy link
Contributor

tzzed commented Apr 16, 2021

I agree but it is just about to have a lazyness way with require.

@montanaflynn
Copy link
Owner Author

Having a dependency used only for development isn't something I would like to add. I think a little more boilerplate but using standard library is a good trade-off to avoid dependency pains for downstream users.

@tzzed
Copy link
Contributor

tzzed commented Apr 17, 2021

It makes sense!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants