Re: GtkD 2.3.0 released, GTK+ with D.
On Monday, 7 October 2013 at 20:47:52 UTC, Mike Wey wrote: GtkD 2.3.0 is now available on gtkd.org: http://gtkd.org/download.html Good work as always!
Re: dunit 0.7.0 released
On Sunday, 29 September 2013 at 21:06:16 UTC, linkrope wrote: https://github.com/linkrope/dunit/tree/v0.7.0 The xUnit testing framework for D is used in production for one year now. Guys, we have at least 5 (!) different unit test projects! Can you cooperate your efforts to create one, but wonderful?
Re: dunit 0.7.0 released
On Monday, 21 October 2013 at 11:09:25 UTC, ilya-stromberg wrote: Guys, we have at least 5 (!) different unit test projects! Can you cooperate your efforts to create one, but wonderful? ...and add it to Phobos review queue ;)
Re: dunit 0.7.0 released
On Monday, 21 October 2013 at 11:58:14 UTC, Jonathan M Davis wrote: On Monday, October 21, 2013 13:48:16 Dicebot wrote: On Monday, 21 October 2013 at 11:09:25 UTC, ilya-stromberg wrote: Guys, we have at least 5 (!) different unit test projects! Can you cooperate your efforts to create one, but wonderful? ...and add it to Phobos review queue ;) I confess that I don't understand why anyone is creating any unit test projects for D, and I'd likely vote against any attempt to add such a thing to Phobos. D has built in unit testing functionality, and it works great. Maybe some additional assert-like functions could be useful (similar to assertThrown or assertNotThrown), but we really don't need much beyond what the language provides. - Jonathan m Davis Yes, you are right if we talk about SIMPLE unit tests. For more complex cases like integration tests you have A LOT of problems. It isn't only my opinion - for example, look at the Higgs, an Experimental JIT Compiler written in D Slides from last dconf (page 57): http://dconf.org/2013/talks/chevalier_boisvert.html
Re: dunit 0.7.0 released
On Monday, October 21, 2013 14:10:13 Dicebot wrote: On Monday, 21 October 2013 at 11:58:14 UTC, Jonathan M Davis wrote: I confess that I don't understand why anyone is creating any unit test projects for D, and I'd likely vote against any attempt to add such a thing to Phobos. D has built in unit testing functionality, and it works great. Maybe some additional assert-like functions could be useful (similar to assertThrown or assertNotThrown), but we really don't need much beyond what the language provides. Sorry but it feels like you didn't really investigate the topic. D built-in unit-test facilities are a basic and extendable framework. Many notable unittest libraries work on top of it (using custom assert helpers and/or __traits(getUnittests)) being at the same time perfectly compatible with raw `dmd -unittest -main -run file.d`. At the very same time built-in reporting facilities are very limited and almost any bigger project will want some extension. Assuming full compatibility with built-in ones and zero external dependencies I don't see why this can't go to Phobos. I know that you can extend the built-in facilities by overriding how assert works and the like. I also see no reason to do so. IIRC, such facilities were even removed at one point, because no one was using them. They were readded after someone complained about wanting them, but every time I see anyone talking about doing anything with those, it seems like overkill to me. And since it's frequently for nonsense like making it so that the tests continue after an assertion fails (which is outright bad practice IMHO), I have a very low opinion of attempts to override the built-in assert for unit tests. If someone wants to present something to the review queue that's related to unit tests, that's fine. But I really don't see any problem with the built-in unit tests facilities and would expect to be against any such submission, particularly since every time I've delved into any discussions on them, what folks are doing with them has seemed like a really bad idea to me. But I guess that we'll just have to wait and see what gets submitted for review, if anything. - Jonathan M Davis
Re: dunit 0.7.0 released
On Mon, 2013-10-21 at 04:58 -0700, Jonathan M Davis wrote: […] I confess that I don't understand why anyone is creating any unit test projects for D, and I'd likely vote against any attempt to add such a thing to Phobos. D has built in unit testing functionality, and it works great. Maybe some additional assert-like functions could be useful (similar to assertThrown or assertNotThrown), but we really don't need much beyond what the language provides. The focus on unit testing is a problem for me, unit testing is but ⅓ of the testing needed. There is integration testing and system testing to consider as well. Not to mention the different features needed of BDD rather than TDD. I appreciate that many people on this list think of anything to do with the JVM beneath contempt ;-) but the JUnit → TestNG → Spock and Cucumber journey is worth considering as a lesson in why not to get too focused on programmer generation of units. Python has the same lessons with the way unittest (aka PyUnit) and py.test are used. It is all about a testing framework supporting unit test, integration test, and system test usage. See Catch for the current C++ front-runner. https://github.com/philsquared/Catch -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: dunit 0.7.0 released
On Monday, 21 October 2013 at 12:24:18 UTC, Jonathan M Davis wrote: I know that you can extend the built-in facilities by overriding how assert works and the like. Overriding assert is dangerous because changes behavior of program itself and lacks context data. Own test runner implemented using __traits(getUnittests) is perfectly safe. And since it's frequently for nonsense like making it so that the tests continue after an assertion fails (which is outright bad practice IMHO), It is absolutely necessary feature in any big project of you want to keep reasonable edit-build cycle times. Tests are always hierarchical naturally, there is no reason to stop the world if completely unrelated ones fail. I have a very low opinion of attempts to override the built-in assert for unit tests. You are right here but it is not needed anymore. But I really don't see any problem with the built-in unit tests facilities and would expect to be against any such submission, There is nothing wrong with built-in ones, just some higher-level tools on top of them are lacking. But I guess that we'll just have to wait and see what gets submitted for review, if anything. Exactly, lets argue in time ;)
Re: dunit 0.7.0 released
On Mon, 2013-10-21 at 16:22 +0200, qznc wrote: […] Somewhat off topic, but out of curiosity: How do you distinguish between integration and system testing? Integration testing is when you test part or all of the system but not in a full deployment context (so possibly still using mocks for the database, network, user interface, etc.) whilst system testing is testing the whole system in a real, albeit test, context. The descriptions I found usually sound like system testing is a special case of integration testing, where you simply integrate all components. No, the difference is mostly in the context of execution of the system. Integration testing is about the interworking of the components and so you can mock out bits as needed to speed things up and drive things more deterministically. System testing allows no use of mocks and must occur in a full deployment setting, with the only compromise being that the deployment is in a sandbox isolated from the rest of the world. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: dunit 0.7.0 released
On Monday, 21 October 2013 at 14:22:31 UTC, qznc wrote: The descriptions I found usually sound like system testing is a special case of integration testing, where you simply integrate all components. There is a certain terminology issue here as system testing may apply to both certain program on its own (and thus come before integration one) and software platform as a whole (being essentially final integration test of all components). I personally favor hierarchical separation into unit - functional - integration.
Re: dunit 0.7.0 released
On Monday, 21 October 2013 at 11:58:14 UTC, Jonathan M Davis wrote: On Monday, October 21, 2013 13:48:16 Dicebot wrote: On Monday, 21 October 2013 at 11:09:25 UTC, ilya-stromberg wrote: Guys, we have at least 5 (!) different unit test projects! Can you cooperate your efforts to create one, but wonderful? ...and add it to Phobos review queue ;) I confess that I don't understand why anyone is creating any unit test projects for D, and I'd likely vote against any attempt to add such a thing to Phobos. D has built in unit testing functionality, and it works great. Maybe some additional assert-like functions could be useful (similar to assertThrown or assertNotThrown), but we really don't need much beyond what the language provides. - Jonathan m Davis 640K ought to be enough for anybody Seriously though, unit testing is a major tool that all languages should have access to. The built-in stuff is adequate for very simple testing on simple types such as asserting something is true, etc. But when you're writing tests for a class that need dependencies then the built-in stuff won't cut it. The framework i'm currently working allows for mocking of dependencies which in itself is a big deal. Replacing dependencies with 'fake' stubs is something which makes unit tests a lot clearer and less complicated. It also means i can override the return value of any method at runtime to pretend returned data is real there too. I've also extended the assert mechanism in the D runtime to create better errors. Instead of just getting: core.exception.AssertError@file(57): Assertion failure You now get: +-- | Failed asserting equal +-- | File: file.d | Line: 57 +-- | ✓ Expected value: (int[]) [1, 2, 3, 4, 5] | ✗ Actual value: (int[]) [1, 2, 4, 5] This is way more clear exactly what and where failed. This is essential when unit testing using structs, arrays, classes, etc.. as you need this information to truly narrow down exactly what failed. Extending stuff like this also helps with overall project reporting, writing to a file or drawing pretty graphs etc..
Re: dunit 0.7.0 released
On Monday, 21 October 2013 at 19:02:45 UTC, Gary Willoughby wrote: On Monday, 21 October 2013 at 11:58:14 UTC, Jonathan M Davis wrote: On Monday, October 21, 2013 13:48:16 Dicebot wrote: On Monday, 21 October 2013 at 11:09:25 UTC, ilya-stromberg wrote: Guys, we have at least 5 (!) different unit test projects! Can you cooperate your efforts to create one, but wonderful? ...and add it to Phobos review queue ;) I confess that I don't understand why anyone is creating any unit test projects for D, and I'd likely vote against any attempt to add such a thing to Phobos. D has built in unit testing functionality, and it works great. Maybe some additional assert-like functions could be useful (similar to assertThrown or assertNotThrown), but we really don't need much beyond what the language provides. - Jonathan m Davis Seriously though, unit testing is a major tool that all languages should have access to. The built-in stuff is adequate for very simple testing on simple types such as asserting something is true, etc. But when you're writing tests for a class that need dependencies then the built-in stuff won't cut it. The framework i'm currently working allows for mocking of dependencies which in itself is a big deal. Replacing dependencies with 'fake' stubs is something which makes unit tests a lot clearer and less complicated. It also means i can override the return value of any method at runtime to pretend returned data is real there too. I've also extended the assert mechanism in the D runtime to create better errors. Instead of just getting: core.exception.AssertError@file(57): Assertion failure You now get: +-- | Failed asserting equal +-- | File: file.d | Line: 57 +-- | ✓ Expected value: (int[]) [1, 2, 3, 4, 5] | ✗ Actual value: (int[]) [1, 2, 4, 5] This is way more clear exactly what and where failed. This is essential when unit testing using structs, arrays, classes, etc.. as you need this information to truly narrow down exactly what failed. Extending stuff like this also helps with overall project reporting, writing to a file or drawing pretty graphs etc.. +1
Re: Pragmatic D Tutorial
On Thu, 10 Oct 2013 00:24:16 +0200, qznc wrote: On Wednesday, 9 October 2013 at 20:22:39 UTC, Dejan Lekic wrote: It is a very nice web-site, but the main column should be wider. Sometimes the source code floats over to the second column... Hm, not here. I suspect a weird font selection for the code. I plan to redesign it at some point anyways. This is the agogo standard theme of Sphinx, which is the only standard theme, where the width is not 100%. Look at this thread and see how many people complain about it... :)
