Improve test coverage about turing.jl HOT 8 CLOSED

I looked into the detail of test coverage and wonder if those functions that haven't been used are just abandoned.

from turing.jl.

I can't remember what functions are not used; can we remove obviously obsolete functions, but keep potentially useful functions somewhere separately (ie. not affecting test coverage).

from turing.jl.

Keep runtest.jl structured
Please check the new runtest.jl file. When adding new tests in the future, keep it structured using the current way so that we can tell which source file we are testing for each test case.

It makes a lot sense to do it this way!

Review of old test cases
I noticed some comments in them are out-of-date. @yebai Can you also have a check and remove unnecessary ones.

Yes, I will take a look!

from turing.jl.

PS. can we create a separate branch (e.g. test-coverage) and keep all work related there?

from turing.jl.

I can't remember what functions are not used; can we remove obviously obsolete functions, but keep potentially useful functions somewhere separately (ie. not affecting test coverage).

I guess we can either

• Create a branch called old-development and come back when some functions are needed, or
• Create a folder called old-src or something in the root path of Turing

Which one do you think is better?

PS. can we create a separate branch (e.g. test-coverage) and keep all work related there?

I wonder whether a separate branch for test coverage is a good idea as we need keep running these updated testes for our updated code.

from turing.jl.

Create a branch called old-development and come back when some functions are needed

Let's do this.

I wonder whether a separate branch for test coverage is a good idea as we need keep running these updated testes for our updated code.

In general we should avoid commit work in progress directly to development or master. Instead, we can keep a new branch for each new task, and create a PR towards to development/master when it is done.

from turing.jl.

The coverage is 85% after removal these files.

In general we should avoid commit work in progress directly to development or master. Instead, we can keep a new branch for each new task, and create a PR towards to development/master when it is done.

Yeah! I'll stick to this as well.

BTW, do you keep the old-development locally?

from turing.jl.

@yebai I wonder if src/distributions/distributions.jl should also be removed?

The flatten function inside is not used anywhere else.

from turing.jl.