On 25 March 2015 at 17:30, Vadim Zeitlin <[email protected]> wrote: > > While we're discussing other "strategic" things, I'd like to also return > to something that was mentioned a couple of times in the past but without > any definitive conclusion, unless I missed it: could we start using CATCH > (http://catch-lib.net/) in the unit tests?
I haven;t requested any discussion, so no conclusion indeed. I just put the CATCH on the https://github.com/SOCI/soci/wiki/Roadmap and was going to start converti,ng/writing the tests, then show it to the public for review. > Currently the tests use assert() which is far from ideal (I could give > details but I'll skip this for now because I think everybody realizes the > problems with assert() already). The only advantage of the current approach > is that it has no third party dependencies. I'd like to use a header-only > testing framework to preserve this advantage as much as possible while also > getting all the nice features you'd expect from such framework and CATCH is > the best candidate I know of. Yes. > Assuming there are no objections to using it, I'd like to add catch.hpp > (https://github.com/philsquared/Catch/blob/master/single_include/catch.hpp) > directly to SOCI repository, e.g. as tests/catch.hpp. I don't think it's > worth the trouble to use a submodule for it, but we could do this too if > people prefer it. Sure. I'd create a branch in the upstream repo, so we can all test and contribute to the new tests transition. Once we're happy, we merge to develop (soon to be master :)) > I am less sure about how to handle the transition from assert() to CATCH. > One possibility would be to just globally replace all asserts with > REQUIRE() macros. This would be suboptimal (if only because some of the > asserts should probably be replaced with CHECK(), to allow the tests to > continue if one of them fails), but should be relatively simple to do. I believe in single assert per test routine/case...see below. > And > if we do this, we should probably also move all the files from tests/assert > one directory level up, as the "assert" part wouldn't make any sense any > more. > > Another possibility would be to start a parallel tests hierarchy in > tests/catch. I'm not too kin on it, mostly because I don't like duplication > but also because this would require changing the CMake files and I'd rather > avoid this. My plan was to keep the current tests and start (re)writing with CATCH in new folder: tests/integrate. (My other plan was to create tests/unit where I aimed to cover common API with plain unit tests.) Finally, along the transition, I had an idea to refactor and clean up the tests slightly to test single thing per routines/cases, as short as possible, with Arrange/Act/Assert principle in mind. Perhaps some modularisation and groupping would be a good idea too. > Finally, it would be possible to just start using CATCH for the checks > without changing anything in the existing ones. I don't like this one too > much neither because it's going to be confusing to have different macros > used in different places, but it's definitely the simplest one. I don't want to get rid of the assert-based tests before CATCH-based tests cover what is already covered. Removal of the assert tests should be the last step before merging the PR/branch to master. > What would be the preferred approach? Or maybe someone sees a better one, > not listed above? Having explained my points above, I don't think that find & replace assert with CATCH macro is the way to go. > And, of course, do we have a consensus for using CATCH in the first place? +1 from me, but even if we don't have concensus now, we can still build new CATCH-based tests, while keeping the assert ones, once it's finished and working, the CATCH will catch, I believe :) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
