Separate out the tests in mp4_test package

[vtpl1]

Can we separate out the tests in separate package for test cases?

This will clean up the main package.

[tobbee]

Hi @vtpl1, thanks for your interest in mp4ff.

I don't think it is a good idea to move the tests to a separate directory.
Intstead, I prefer to keep the tests for e.g. the StppBox defined in stpp.go in a sibling test file stpp_test.go.
That makes it easy to check what tests are available, how to use the functions and methods of that box etc.
Moving all the tests to another catalogue will make the development a little harder, in my view.
It is also very common setup for Go packages.

Another possibility in Go is to keep the files where they are but use e.g. mp4_package inside the tests in the mp4 directory. This will force the tests to be black-box tests. I'm more positive to that, but every test file will then have an import
with the full GitHub path of the mp4 package which means that everybody who has an own fork will need to patch all files with their fork address. Given that this repo has a lot of forks, I therefore don't think this change is desired either.

I hope you understand my view-point?

[vtpl1]

Dear Torbjörn @tobbee,
Thank you for elaborate explanation.

I am suggesting to have mp4_test package to be used throughout the repository.
We can see it is being used in mp4/initsegment_create_test.go and mp4/ntp64_test.go

Separating the tests in the same folder as separate package can clearly define publicly exposed members of the structures.

I feel that the golang does not clearly provide solution for forked projects. The forked projects need to use full namespace as "github.com/Eyevinn/mp4ff/bits" to use other packages in the same repo.

This is just a suggestion, but I fully respect your viewpoint.

[tobbee]

I did an effort to change the test files in the mp4 repo. That was a bit more work than I expected, but I think the tests got a bit better by becoming true black-box tests.

[vtpl1]

Ah great, I was thinking of raising a PR, let me know if you feel so.

I tried to do the same and found that API s can be cleaned further.

[vtpl1]

Oh I see that we already have an PR. #415