Refactor firrtlTests under firrtl package

Type of issue: other enhancement

The separation of firrtlTests from firrtl results in some annoyances (or lots of monkeying around) to test private behavior. E.g., consider:

package firrtl

class X private [firrtl] 

If I can access this constructor from firrtl, it seems logical that I’d like to test it’s behavior in firrtlTests. However, by placing all the tests inside firrtlTests, this is private to testing. There’s some hackery you can do to get at private methods, but that seems inelegant.

As far as I understand it, there’s no need to place tests in a separate package. Those jars are built separately and not included in any fat jar assembly or publishing (as far as I’m aware).

I’d go one step further with this and suggest that the testing packages should match the source packages exactly in terms of names and directory structure.

What is the use case for changing the behavior?

Make it so that you can test private things in package firrtl or sub-packages.

Impact: no functional change

Development Phase: proposal

Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. Stack Overflow, gitter, etc)

This problem exists for some of the other BIG6 packages (Chisel notably).

[chick]

There can be large chunks of complicated code that can be completely hidden behind an API. I would not feel comfortable just believing the API is going to ensure that code works, and furthermore, if you believe in TDD at all shouldn’t you be writing all your code with tests to guide you. Rant over. Place me in the test everything camp

[seldridge]

Closing in favor of fine-grained packaging on a case-by-case basis.