02:31:53  * madewokherdjoined
02:37:19  * madewokherdquit (Remote host closed the connection)
02:48:29  * AtashiConquit (Quit: AtashiCon)
02:48:49  * AtashiConjoined
07:18:12  * ender`joined
13:52:15  * auroraeosrosejoined
14:29:36  * bcraigjoined
16:15:19  * Jeanne-Kamikazejoined
16:18:05  <ender|>https://jira.atlassian.com/browse/CONF-32190
17:03:22  * vpovirkjoined
17:21:12  * drdanzjoined
17:45:38  * Disgaeaquit (Ping timeout: 252 seconds)
17:47:49  * Disgaeajoined
18:09:26  * Jeanne-Kamikazequit (Quit: Leaving)
18:40:56  * alkaline_joined
18:59:04  * ender`quit (Quit: Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday's code. -- Christopher Thompson)
19:05:11  * ender`joined
19:25:49  * Jeanne-Kamikazejoined
20:29:00  * FearTheCowboyjoined
20:29:00  * FearTheCowboyquit (Changing host)
20:29:00  * FearTheCowboyjoined
20:30:05  <FearTheCowboy>When I'm setting up test projects for a solution that has many fine-grained projects, should I have 1 test project per project (ie, keep the tests fine-grained as the code) or have one larger test project
20:30:21  <FearTheCowboy>I'm leaning towards fine-grained...
20:30:27  <FearTheCowboy>auroraeosrose ?
20:30:47  <auroraeosrose>fine grained + some kind of script to run them all
20:30:55  <auroraeosrose>so you can do them minutely when working
20:30:59  <auroraeosrose>but can run em all easy
20:31:02  <FearTheCowboy>that's what I was thinking too
20:36:51  * alkaline_seconds auroraeosrose's test-per-project recommendation.
20:37:34  * alkaline_changed nick to alkaline
20:37:46  * alkalinequit (Changing host)
20:37:47  * alkalinejoined
20:52:45  * drdanzquit (Remote host closed the connection)
20:54:23  * drdanzjoined
21:04:23  * drdanzquit (Remote host closed the connection)
21:26:08  * Jeanne-Kamikazequit (Quit: Leaving)
21:27:14  <FearTheCowboy>*sigh*
21:27:56  <FearTheCowboy>Visual Studio 2013 has a unit test framework for C++ , along with enough integration into VS itself that it would seem pretty dumb not to use it.
21:28:03  <FearTheCowboy>even if I don't particularly like it.
21:29:20  <bcraig>I couldn't find documentation on how to plug into it
21:29:36  <bcraig>that is, if I was writing my own tests, with my own "main"
21:29:42  <FearTheCowboy>I can't either. There must be some somewhere, because there's a google unit test plugin for it
21:29:43  <vpovirk>is the framework open source and available on linux?
21:30:11  <FearTheCowboy>no, not OSS, not avail on linux
21:30:43  <FearTheCowboy>there is a googletest runner
21:30:55  <FearTheCowboy>that should integrate just as well... and *that* should work on Linux
21:31:08  <bcraig>I couldn't even tell if VS scrapes stdout / stderr, or if it is expecting a magic xml file to be somewhere
21:31:25  <FearTheCowboy>I was wondering the same thing
21:33:51  <bcraig>only spent an hour or so looking though
21:34:54  <bcraig>process explorer + procmon can probably let you reverse engineer a microsoft test project to some degree, but that would probably be more effort that it's worth
21:39:05  <FearTheCowboy>here's the source to the googletestrunner extension for VS...
21:39:07  <FearTheCowboy>https://github.com/markusl/GoogleTestRunner
21:39:12  <FearTheCowboy>written in f# tho'
21:39:14  <FearTheCowboy>*blink*
21:39:42  <bcraig>I tried to learn f# once. Was a bit surprised to find out it has something called "the banana operator"
21:39:50  <FearTheCowboy>lol
21:40:05  <bcraig>|) sort of looks like a banana, I guess
21:41:15  <FearTheCowboy>This one is written in c# at least: http://visualstudiogallery.msdn.microsoft.com/f8741f04-bae4-4900-81c7-7c9bfb9ed1fe
21:41:42  <alkaline>do VS 2013's managed/native C++ unit test projects automatically populate (scan) when added to an existing solution?
21:43:13  <alkaline>[i guess not... which begs the question, why not?]
21:43:20  <FearTheCowboy>I don't know how deep the 'automatic' is, but as I write a new test method in c++ it shows up in the test explorer.
21:43:34  <FearTheCowboy>hmmm. it's not really clear *what* it's doing.
21:45:30  <FearTheCowboy>one for xUnit.net ... http://visualstudiogallery.msdn.microsoft.com/463c5987-f82b-46c8-a97e-b1cde42b9099 ... I don't it supports c++ tho.
21:47:34  <FearTheCowboy>xUnit++ test adapter: https://bitbucket.org/moswald/xunit/src/fa374dcddb304371669186fcff7dc23bbfa40e00/xUnit%2B%2B.VsRunner/?at=default
21:47:42  <FearTheCowboy>looks like it's not terribly heavy.
21:48:04  <alkaline>fear... i assume you're looking for a Runner?
21:48:10  <alkaline>and not a generator?
21:48:13  <FearTheCowboy>Yeah
21:48:27  <FearTheCowboy>found a bit of docs! https://blogs.msdn.com/b/bhuvaneshwari/archive/2012/03/13/authoring-a-new-visual-studio-test-adapter.aspx?Redirected=true
21:49:22  <FearTheCowboy>You have to implement ITestDiscoverer and ITestExecutor
21:50:59  <alkaline>too bad the VS ALM Rangers don't seem to have anything
21:51:12  <alkaline>(they only have unit test generator as out-of-band from VS ALM)
21:53:43  <FearTheCowboy>I'm grabbing the VS SDK 2013 ... I think the interfaces are in there.
21:53:48  <FearTheCowboy>maybe there is some docs too :D
21:54:13  <bcraig>well, a search for ITestDiscoverer didn't hit anything official. The best hit was the blog you already linked
21:54:24  <alkaline>http://www.visualassert.com/unit-testing-framework/ ?
22:12:19  <FearTheCowboy>ITestDiscoverer is in the Microsoft.VisualStudio.TestPlatform.ObjectModel.dll
22:12:38  <FearTheCowboy>well, the interfaces are simple enough.
22:12:56  <FearTheCowboy>1 fn in ITestDiscoverer and 3 in ITestExecutor
22:13:09  <FearTheCowboy>perhaps I can make an adapter for Bandit
22:13:24  <FearTheCowboy>and not have to worry about using VS's non-portable testing framework
22:19:02  <alkaline>this is probably more useless info from me, but have you heard of Igloo? (http://igloo-testing.org/testrunner.html)
22:19:43  <bcraig>"or fails with a return value corresponding to the number of failing tests"
22:19:46  <bcraig>lots me right there
22:19:55  <bcraig>lots of command lines wrap the return values at 256
22:20:04  <bcraig>err, lost me
22:20:13  <FearTheCowboy>bandit looks a lot like igloo : http://banditcpp.org/index.html
22:20:50  <FearTheCowboy>LOL
22:20:55  <FearTheCowboy>Same guy!
22:20:55  <alkaline>same guy, LOL
22:21:18  <FearTheCowboy>now *that*'s funny
22:21:28  <bcraig>I wonder why they look so similar...
22:22:16  <FearTheCowboy>Bandit is very C++11 oriented
22:22:40  <FearTheCowboy>doesn't use macros for declaring tests,etc
22:22:54  <bcraig>I noticed it doesn't support vs2010. Was looking for a similar table in igloo
22:23:16  <bcraig>I haven't really found an alternative to macros to get good output
22:23:49  <bcraig>When a test fails, I really want to see file and line numbers. I also like to see the expression that failed, plus the actual values.
22:24:03  <bcraig>Those requirements generally hint strongly at macros
22:24:40  <FearTheCowboy>Well, file and line numbers have to be supplied by compiler macros, sure.
22:24:48  <bcraig>I do like how bandit -doesn't- steal your main.cpp
22:25:00  <bcraig>most test frameworks steal your main()
22:26:11  <FearTheCowboy>Well, bandit does require you to call bandit::run(), but at least you get to control that :D
22:27:27  <bcraig>Well, that little bit of freedom makes it possible to host the tests in a DLL
22:27:33  <bcraig>and I've had need of that before
22:27:35  <FearTheCowboy>Indeed it does.
22:36:23  <FearTheCowboy>The only sample I can find for a test runner is https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-10-33-50-87/XmlTestAdapter.zip
22:36:31  * vpovirkquit (Read error: Connection reset by peer)
23:47:00  * ender`quit (Quit: Little expense had been spared to create the impression that no expense had been spared.)