I include PDB files because they can be very useful for debugging into the framework from the tests. As an added bonus if you turn on "Source Server" support then you can step into framework code directly. There is a small cost for loading up the PDB when the first exception is thrown but I don't think it's too significant in the grand scheme of things. We do ship Gallio modules with optimization turned on. Even so, so little of what Gallio does is compute bound; mostly it spends time waiting for I/O or for tests to run. As for debugger performance, [NonUserCode] may help some but the debugger is still chugging through a deep stack. Unfortunately the only effective way to fix this is to reduce the stack depth. I'll probably have to rewrite chunks of MbUnit using continuation-passing style or spinning off new threads or something. Jeff.
_____ From: [email protected] [mailto:[email protected]] On Behalf Of Bruno Wouters Sent: Tuesday, June 30, 2009 1:49 PM To: [email protected] Subject: MbUnit Re: Test count Indeed that could have some nice purposes. But because we can see which changes caused the query count increase we don't really need such setup, yet.. A single build takes an average of 20 minutes so I would like to keep the overhead as low as possible. Currently we display the query count/coverage/. statistics in graphs in teamcity. On another note, I saw that the pdb files are included in the setup of gallio. Is this needed? Doesn't this slow down stuff? I think this also causes the occasional popups requesting the source file location for a mbunit/gallio class (while debugging). Or am I wrong.? And for the slow debugging (stepping through code) issues. If I remember correctly, you posted on some blog that this could be because of the big call stack and is solved by disabling automatic property evaluation. Maybe adding an non user code attribute could help? I did not have time to test so I don't know if it would help. (http://msdn.microsoft.com/en-us/library/system.diagnostics.debuggernonuserc odeattribute.aspx) Or is this already solved? J Anyway, keep up the good work! Greets, Bruno From: [email protected] [mailto:[email protected]] On Behalf Of Jeff Brown Sent: dinsdag 30 juni 2009 19:01 To: [email protected] Subject: MbUnit Re: Test count How about logging statistics out of band to a separate file? For example, you could emit a CSV file with test names and number of queries. Then you can subject this data to analysis in another tool. [TearDown] public void TearDown() { int numberOfQueriesForThisTest = ...; using (FileWriter writer = new FileWriter("logfile.csv", FileMode.Append)) writer.WriteLine("\"{0}\",{1}", TestContext.CurrentContext.Test.Name, numberOfQueriesForThisTest); } Jeff. P.S. Eventually I would like Gallio to have a statistics gathering and reporting API. If you have any thoughts on this, let me know. _____ From: [email protected] [mailto:[email protected]] On Behalf Of Bruno Wouters Sent: Tuesday, June 30, 2009 2:58 AM To: [email protected] Subject: MbUnit Re: Test count We have some logic that counts the sql queries that NHibernate executes. To get a better view I also wanted the average query count per test. To calculate that I needed the total number of tests executed. With these numbers we can detect if someone checks in code that generates to much queries. (n+1 problems etc) Greets, Bruno From: [email protected] [mailto:[email protected]] On Behalf Of Jeff Brown Sent: dinsdag 30 juni 2009 10:31 To: [email protected] Subject: MbUnit Re: Test count Yup. So if you wanted to grab the outcome of the fixture as a whole you could check it in Dispose or TestFixtureTearDown. Anyways, I'm curious what your use-case is. Several people have asked for similar features to manipulate parts of the test report during test execution. We do have a separate "test runner extension" mechanism whereby you can extend the behavior of the test runner to upload results into a test database or perform other tasks of that sort. Jeff. _____ From: [email protected] [mailto:[email protected]] On Behalf Of Bruno Wouters Sent: Monday, June 29, 2009 11:41 PM To: [email protected] Subject: MbUnit Re: Test count Hi Jeff, Thanks for the fast response! Isn't the dispose method called when the fixture is disposed? (So not after every test?) Greets, Bruno From: [email protected] [mailto:[email protected]] On Behalf Of Jeff Brown Sent: maandag 29 juni 2009 18:09 To: [email protected] Subject: MbUnit Re: Test count You can only get Statistics and other Report objects from the context of the test runner itself, not from within the tests. However within the tests you can read TestContext.Current.Outcome during TearDown or Dispose to determine whether the test passed or failed. Jeff. _____ From: [email protected] [mailto:[email protected]] On Behalf Of Bruno Wouters Sent: Monday, June 29, 2009 2:39 AM To: 'MbUnit.User' Subject: MbUnit Test count Hi all, I'm trying to get the test count (excl skipped) when my custom log4net appender is being closed. I saw that there is a Statistics class but how can I access the instance of it? Thanks! Greets, Bruno <BR <BR <BR --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MbUnit.User" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/MbUnitUser?hl=en -~----------~----~----~----~------~----~------~--~---
