Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Feature/0557 fvar test kit #562
First pull request for #557 showing how the framework will apply to binary functions with scalar returns. The reason this is being done as a separate pull request is that there will be a lot of files being removed and I wanted to lay out the general pattern.
Remove hundreds of lines of test code per function and make tests more thorough and easier to write for new functions.
How to Verify:
Please look at the implementation and, of course, the tests.
Added some doc for the test framework.
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company):
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:
@syclik and @seantalts --- no idea how it's looking for dependencies, but it found a mention of
I think that might be the test that Daniel added back in with fixes to it? Have you merged develop into this branch recently?…
On Sat, Jun 24, 2017 at 13:27 Bob Carpenter ***@***.***> wrote: Jenkins, retest this please — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#562 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAxJ7PcwtldgKyHtL_JRk9GBy6sfnWGxks5sHUcPgaJpZM4N2Ox0> .
Go for it! I'll spot check it just to make sure we didn't miss any major test behaviors (which I doubt, but doesn't hurt to double check). I'll stay out of code-level comments.…
On Jun 26, 2017, at 1:02 PM, seantalts ***@***.***> wrote: Mind if I review this one? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@syclik --- You mean test a second function that throws to make sure the throws test works?
I'm also not testing the array writer pattern for all the different types of inputs.
Would you like me to set up a half dozen or so mock functions and test those to cover more of the combinatorics of input types and exception throwing?
Also, any idea how to test throwing different types of exceptions in a general framework? Almost all of our functions only throw a handful of error types, but the only way I see how to do this is collect instances of all of them in separate containers. I just don't see how to get type info in otherwise.
No, just the part of the testing framework that tests for exceptions. It was outlined in the original issue. I just didn't find it in the implementation here.
From the original issue #557:
If you just want to hold off until we implement the test for a function that throws, that's fine.
Nope. No need. No need to test the test code.... seems clear enough and if there are problems, we'll fix them as they come up.
No wonder Google Test uses macros. Would you be offended by a hybrid macro solution? If not, I can see us having things like
Ah, never mind on that last point. It's been so long since this went into a pull request I forgot that I rewrote it to do a single test at a time. For that, I can specify the expected expectation type as a template parameter.
Personally, I'd rather stay away from macros and code generation to the extent possible.