classes for use in tests

[Krzysztof Sakrejda]

I wrote a writer class that counts how many times its been called to use in a bunch of services unit tests. Is there a way to share it among test files instead of literally placing the class in each file? I guess I could put the class in src/test/unit/services with the tests and then just #include it. Is that the right way to go about it here?

K

[Daniel Lee]

Yes. I'm guessing it's a *.hpp file. That's perfectly fine and we've done that before.

Thanks!

On Tue, Aug 30, 2016 at 4:02 PM, Krzysztof Sakrejda <krzysztof...@gmail.com> wrote:

I wrote a writer class that counts how many times its been called to use in a bunch of services unit tests.  Is there a way to share it among test files instead of literally placing the class in each file? I guess I could put the class in src/test/unit/services with the tests and then just #include it. Is that the right way to go about it here?

K

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Betancourt]

I would follow the pattern for common Stan programs across tests.
So, yeah, do something like src/test/unit/services/writer/test_writer
and then just include that anywhere without duplication.

On Aug 30, 2016, at 9:02 PM, Krzysztof Sakrejda <krzysztof...@gmail.com> wrote:

> I wrote a writer class that counts how many times its been called to use in a bunch of services unit tests. Is there a way to share it among test files instead of literally placing the class in each file? I guess I could put the class in src/test/unit/services with the tests and then just #include it. Is that the right way to go about it here?
>
> K
>

> --
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.

[Michael Betancourt]

Also, if the refactor separates out what the API provides and what
the client has to provide, then it should be straightforward to add
a test implementations of the client provisions into src/test/.

[Krzysztof Sakrejda]

Thanks for the quick replies. I think what you're saying (Michael) is that the mock callbacks and mock writers we use in testing can be re-used by a lot of the unit tests so if their functionality can be better thought out we could just put them into the base directory (src/test) and use them to test writers/utils/services. I'll look into it when I look at the Stan tests more broadly. K

[Bob Carpenter]

They should be as far down as makes sense in the source tree
under src/test (or src/test/unit if they're unit tests).

They should go in their own stan::test or stan::test::unit
namespace and have proper header guards to make things
safer to use with multiple tests running in the same
translation unit.

- Bob