- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About 1.2

by Dale Henrichs

I saw your changes and they did appear to be consistent with the changes I had made ... Dale On Feb 27, 2011, at 1:56 PM, StÃ©phane Ducasse wrote: > I think that I fixed the issue with Shout. > I'm trying to load Pharo configuration now :( > > Stef > >>> >>> >>> >>> How can XML in 1.2 impacts 1.1 ??????? >>> >>> >> It's not XML, there is another problem. >> >> Status: >> => 1.2 now builds, without Mocketry. But that has been fixed in the meantime, so we can add it back. >> (it seems removing is a far better way to get people to fix something than anything else. >> I will do the same with the MethodWrapper package, you will see how quickly this gets fixed >> *after* removing it, but never without removing it...) >> >> => 1.1 does not build. I don't know why. *first* release 1.2, *than* release 1.1.2... >> >> => From the test side of things, there are only two things left in 1.2 >> -> MethodWrappers has test that fails 50% of the time. This will be solved by removing the package. >> -> there are Obsoletes after running tests. here I think as this is only after running tests, we can defer >> to 1.3 and remove the test for obsoletes in 1.2 >> >> >> Besides that, there are a number of things that need to be done for 1.2, they are listed here: >> >> http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage >> >> 1.2 can only be released if this list is empty. >> >> Marcus >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> > >

Feb. 28, 2011

Re: [Pharo-project] Gaelli vs. Galli??

by Alexandre Bergel

Same guy. "ae" and "Ã¤" are the character Alexandre Le 27 fÃ©vr. 2011 Ã 21:32, "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> a Ã©crit : > Are Gaelli and Galli the same person? If so, is there a typo, or is it simply that the name does not translate easily? > > [5] M. Gaelli, O. Nierstrasz, and S. Ducasse. One-method commands: Linking > methods and their tests. In OOPSLA Workshop on Revival of Dynamic > Languages. Citeseer, 2004. > > [6] M. Galli, M. Lanza, O. Nierstrasz, and R. Wuyts. Ordering broken unit > tests for focused debugging. In Software Maintenance, 2004. Proceedings. > 20th IEEE International Conference on, pages 114â123. IEEE, 2004. > > Given the identities of the other authors, this seems the easiest place to clarify it :) > >

Feb. 28, 2011

Re: [Pharo-project] Gaelli vs. Galli??

by Serge Stinckwich

Yes same guy. On Mon, Feb 28, 2011 at 7:32 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Are Gaelli and Galli the same person? Â If so, is there a typo, or is it simply that the name does not translate easily? > > [5] M. Gaelli, O. Nierstrasz, and S. Ducasse. One-method commands: Linking > methods and their tests. In OOPSLA Workshop on Revival of Dynamic > Languages. Citeseer, 2004. > > [6] M. Galli, M. Lanza, O. Nierstrasz, and R. Wuyts. Ordering broken unit > tests for focused debugging. In Software Maintenance, 2004. Proceedings. > 20th IEEE International Conference on, pages 114â123. IEEE, 2004. > > Given the identities of the other authors, this seems the easiest place to clarify it :) > > > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Feb. 28, 2011

Re: [Pharo-project] introducing RPackage :)

by Carla F. Griggio

I'll try it with smallUML, it would be great to link diagrams to a package instead of a special class like it's done now :) On Sat, Feb 26, 2011 at 6:07 PM, jannik.laval <jannik.laval(a)gmail.com>wrote: > Hi, > > There is also a nighty build in hudson server. > > Cheers, > Jannik > > On Feb 26, 2011, at 21:48 , StÃ©phane Ducasse wrote: > > > > > On Feb 26, 2011, at 8:12 PM, Tudor Girba wrote: > > > >> Hi, > >> > >> We use RPackage in Moose, and it works fine. We only encountered a small > problem raised when renaming a class, but Cyrille fixed that, too. I am > quite confident in it. > >> > >> The way to load it is like this (different repo): > >> Gofer new > >> squeaksource: 'PharoTaskForces'; > >> package: 'ConfigurationOfRPackage'; > >> load. > >> (Smalltalk at: #ConfigurationOfRPackage) perform: #loadDefault. > >> > >> The translation of SystemChangeNotifier into Announcements happens in > SystemAnnouncements package. > > > > thanks doru I will talk with cyrille monday. > > > >> > >> Just a note, until we can remove the SystemChangeNotifier, we have to > first get Monticello work with RPackage and > > > > What do you mean by "we have to first get Monticello work with RPackage " > It does not? > > > > I will have a look. > > > >> SystemAnnouncements. Afterwards, we should hook Announcements directly > in the system, and yet afterwards remove the categories and get the tools > work with RPackage. > >> > >> Cheers, > >> Doru > >> > >> > >> On 26 Feb 2011, at 18:59, StÃ©phane Ducasse wrote: > >> > >>> Hi guys > >>> > >>> I would like to give a try to introduce RPackage = a complete rewrite > of PackageInfo. > >>> Moose people use it and I will sync with them to know. > >>> > >>> It would be great if some of you could load and play with the system > >>> > >>> > >>> Gofer new > >>> squeaksource: 'PharoInbox'; > >>> package: 'ConfigurationOfRPackage'; > >>> load. > >>> (Smalltalk at: #ConfigurationOfRPackage) perform: #loadDefault. > >>> > >>> Note that RPackage is based on announcement. So there is just one place > that register to systemNotifier. > >>> So one of the following goal is to remove SystemChangeNotifier and > replace it with announcement. > >>> > >>> Stef > >>> > >>> > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing should have the right to be different." > >> > >> > >> > >> > > > > > > >

Feb. 28, 2011

[Pharo-project] Gaelli vs. Galli??

by Schwab,Wilhelm K

Are Gaelli and Galli the same person? If so, is there a typo, or is it simply that the name does not translate easily? [5] M. Gaelli, O. Nierstrasz, and S. Ducasse. One-method commands: Linking methods and their tests. In OOPSLA Workshop on Revival of Dynamic Languages. Citeseer, 2004. [6] M. Galli, M. Lanza, O. Nierstrasz, and R. Wuyts. Ordering broken unit tests for focused debugging. In Software Maintenance, 2004. Proceedings. 20th IEEE International Conference on, pages 114â123. IEEE, 2004. Given the identities of the other authors, this seems the easiest place to clarify it :)

Feb. 28, 2011

Re: [Pharo-project] Good reference on time on unit testing?

by Norbert Hartl

On 27.02.2011, at 23:19, Schwab,Wilhelm K wrote: > Norbert, > > Have you ever read of shops where people throw code at features and never much bother to test what they are doing, because it is "testing's" job to catch the bugs ? I had read about it too... > Yes, I did. Nearly all of the teams/developers I had to deal with were exactly like this. And myself 12 years ago wasn't that much better (before I encountered XP and started to think about it). All of what I have written is the outcome of a long history of pain. Let's call it experience. I know how hard it is to convince people that testing is useful. As long as testing is considered as additional effort you won't convince developers for the extra work and you won't convince manager for the extra money. That makes two problems. It seems that forecasting to spend more work on something to have to do less in overall is considered black magic. The natural reaction to this is disbelieve. > I understand what you are saying. > I know you do. I would be really glad to be helpful. But I didn't have a recipe to get it going by argueing. I have a good and an evil way of treating it. The good one is to be a role model in the daily work. The evil one is to write tests for others that are red :) Norbert > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Norbert Hartl [norbert(a)hartl.name] > Sent: Sunday, February 27, 2011 2:51 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Good reference on time on unit testing? > > On 27.02.2011, at 13:58, Schwab,Wilhelm K wrote: > >> Norbert, >> >> Excellent points - I take exception with only one: you assume that all developers test - that is sadly not true. I am involved with a group who seem to think that a handful of tests added at the last minute will somehow magically fix their problems. >> > It seems I wasn't clear on this one. I'm trying to making a point that there is no distinction between "testing" - "no testing" but between "testing" - "writing tests". If you take compilation you test the code for syntax and language quirks. If a developer runs the program he develops than he is testing already. Testing and running a program is the same form that point of view. He takes input parameter and expects output parameter. That is testing. The point is just that developers do it manually and that is not reproducable. So there is no real difference between manual testing all the time and written test case. Only that repeating the testing procedure is boring and therefor supposed to be done by a machine. So if developers could see that the just need to put the work they already doing into a test will ease the work without changing much. They are just changing style and save time. That's it. Talking about 100% test coverage and holistic views about what the perfect testing could be doesn't help. > >> I have no problem arguing that testing (if done well) can/will reduce overall development time; the question is how much of that time one should expect to devote to writing and maintaining unit and acceptance tests? >> > I understand your intention but the view is inapropriate. Coding and testing aren't two things. It is something that belongs together (if you changed coding style). So that's why it is hard to estimate a time that should be spent. To me it is more comparabale to this: We all know collections are great. Imagine someone asking you "Can anyone recommend a good reference on the amount of time one should expect to spend writing code that uses collections?". What would you say? There is no answer. That doesn't mean you can't solve the problem. But you won't solving it by saying "It is 38.345 % of the time". If people don't get it you have to convince and/or teach them. I had several times where I could show the developer that he is gaining time from doing it. That works. Everything else is targeted towards excel manipulators. > > Norbert > > >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Norbert Hartl [norbert(a)hartl.name] >> Sent: Sunday, February 27, 2011 5:41 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Good reference on time on unit testing? >> >> Hi, >> >> On 27.02.2011, at 04:52, Schwab,Wilhelm K wrote: >> >>> Hello all, >>> >>> Can anyone recommend a good reference on the amount of time one should expect to spend writing tests? I will have to be the messenger (will be wearing running shoes just in case...), but I want the message to come from a solid source. >> >> I find that really hard to answer. To me the problem is the question itself. I heard the "..amount of time one should expect to spend writing tests?" so often in companies and I think it was always exactly this phrase. While the question is valid it gives the impression there is something that decucts time from your "normal" development work. So the people that are asking this question are often managing people that have read something about code quality and they want to apply _this_ to their teams. >> The definition over time is troublesome, too. Testing is not easy. Everything you read about testing gives you the impression that everyone knows how to test and that those developers are just too lazy. And that is not true. Most developers I met had problems to see what testing is all about. The don't see interfaces as provable promises etc. So if you tell any of these developers they should spend 1 hour a day in testing than you will get tests that are counter-productive. My favorite example is the one where you have any composite object with an add method. Than the test goes like adding something via the interface and then try to access the internal array and check if it is of size 1. To me it is the same as with documentation. I prefer to have less documentation than useless documentation. >> >> So every developer is testing in some way. You either test and debug on the way in an unstructured form or you write tests. To me writing tests is not an add-on it is a change in working style. From this point of view I would state that the time I need to spend _additionally_ for testing is negative. I grew up with a print statement being the ultimate debugging tool. A print/debugging statement is added at the time of debugging and probably removed if the error seems to be fixed. That can lead to a situation where you do this multiple times. Writing the same as a test (and that forces you to produce more fine grained code) you will have a saving in time and a little assurance about regression. Regression debugging (debugging it again later) is much more time spent because you have to fix the error _and_ you need to focus again on that problem (which takes most of the time). So the point in writing tests is not to spend time but to save time. >> >> The amount of time one should expect to spend writing tests is less than the time you need to spend for testing otherwise. :) >> >> Norbert >> > > >

Feb. 27, 2011

Re: [Pharo-project] Good reference on time on unit testing?

by Schwab,Wilhelm K

Great, an idealist :) In this case, the problem is flipped: they want tests, but expect that a hurried effort will fix all of their problems. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Steven Baker [steven(a)stevenrbaker.com] Sent: Sunday, February 27, 2011 3:31 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Good reference on time on unit testing? Oh! I never worry about "proving" it. When I've worked for clients who have insisted that I leave the testing out because they don't want to "pay extra" for the time spent, I simply don't push the tests to their repo. I test for myself, because I have a personal commitment to do the best job possible. -Steven On Sun, Feb 27, 2011 at 12:11 PM, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: > Steven, you're making perfect sense to me, and I think almost everyone here > agrees with you. > > Bill's problem (if I've understood him correctly) is that he needs to > convince some pointy-haired-boss-type person, by directing him or her to a > well-respected "official" statistic that "proves" what we all know to be > true from experience. Sadly, I think it will be hard to find it :-( > > -- > Cheers, > Peter > > On Sun, Feb 27, 2011 at 9:04 PM, Steven Baker <steven(a)stevenrbaker.com> > wrote: >> >> I've always felt that "test driving" code actually results in negative >> time spent on "testing". I spend (and everyone I know that tests well >> does as well) a lot less time writing code test-first than I ever >> would writing the same code without the tests first. Also, I spend far >> less time (almost none) manually testing functionality. So TDD results >> in net negative time difference. >> >> (Apologize if I'm incoherent, the cold and flu drugs are strong in this >> one.) >> >> -Steven >> >> On Sun, Feb 27, 2011 at 11:51 AM, Norbert Hartl <norbert(a)hartl.name> >> wrote: >> > >> > On 27.02.2011, at 13:58, Schwab,Wilhelm K wrote: >> > >> >> Norbert, >> >> >> >> Excellent points - I take exception with only one: you assume that all >> >> developers test - that is sadly not true. I am involved with a group who >> >> seem to think that a handful of tests added at the last minute will somehow >> >> magically fix their problems. >> >> >> > It seems I wasn't clear on this one. I'm trying to making a point that >> > there is no distinction between "testing" - "no testing" but between >> > "testing" - "writing tests". If you take compilation you test the code for >> > syntax and language quirks. If a developer runs the program he develops than >> > he is testing already. Testing and running a program is the same form that >> > point of view. He takes input parameter and expects output parameter. That >> > is testing. The point is just that developers do it manually and that is not >> > reproducable. So there is no real difference between manual testing all the >> > time and written test case. Only that repeating the testing procedure is >> > boring and therefor supposed to be done by a machine. So if developers could >> > see that the just need to put the work they already doing into a test will >> > ease the work without changing much. They are just changing style and save >> > time. That's it. Talking about 100% test coverage and holistic views about >> > what the perfect testing could be doesn't help. >> > >> >> I have no problem arguing that testing (if done well) can/will reduce >> >> overall development time; the question is how much of that time one should >> >> expect to devote to writing and maintaining unit and acceptance tests? >> >> >> > I understand your intention but the view is inapropriate. Coding and >> > testing aren't two things. It is something that belongs together (if you >> > changed coding style). So that's why it is hard to estimate a time that >> > should be spent. To me it is more comparabale to this: We all know >> > collections are great. Imagine someone asking you "Can anyone recommend a >> > good reference on the amount of time one should expect to spend writing code >> > that uses collections?". What would you say? There is no answer. That >> > doesn't mean you can't solve the problem. But you won't solving it by saying >> > "It is 38.345 % of the time". If people don't get it you have to convince >> > and/or teach them. I had several times where I could show the developer that >> > he is gaining time from doing it. That works. Everything else is targeted >> > towards excel manipulators. >> > >> > Norbert >> > >> > >> >> ________________________________________ >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> >> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Norbert Hartl >> >> [norbert(a)hartl.name] >> >> Sent: Sunday, February 27, 2011 5:41 AM >> >> To: Pharo-project(a)lists.gforge.inria.fr >> >> Subject: Re: [Pharo-project] Good reference on time on unit testing? >> >> >> >> Hi, >> >> >> >> On 27.02.2011, at 04:52, Schwab,Wilhelm K wrote: >> >> >> >>> Hello all, >> >>> >> >>> Can anyone recommend a good reference on the amount of time one should >> >>> expect to spend writing tests? I will have to be the messenger (will be >> >>> wearing running shoes just in case...), but I want the message to come from >> >>> a solid source. >> >> >> >> I find that really hard to answer. To me the problem is the question >> >> itself. I heard the "..amount of time one should expect to spend writing >> >> tests?" so often in companies and I think it was always exactly this phrase. >> >> While the question is valid it gives the impression there is something that >> >> decucts time from your "normal" development work. So the people that are >> >> asking this question are often managing people that have read something >> >> about code quality and they want to apply _this_ to their teams. >> >> The definition over time is troublesome, too. Testing is not easy. >> >> Everything you read about testing gives you the impression that everyone >> >> knows how to test and that those developers are just too lazy. And that is >> >> not true. Most developers I met had problems to see what testing is all >> >> about. The don't see interfaces as provable promises etc. So if you tell any >> >> of these developers they should spend 1 hour a day in testing than you will >> >> get tests that are counter-productive. My favorite example is the one where >> >> you have any composite object with an add method. Than the test goes like >> >> adding something via the interface and then try to access the internal array >> >> and check if it is of size 1. To me it is the same as with documentation. I >> >> prefer to have less documentation than useless documentation. >> >> >> >> So every developer is testing in some way. You either test and debug on >> >> the way in an unstructured form or you write tests. To me writing tests is >> >> not an add-on it is a change in working style. From this point of view I >> >> would state that the time I need to spend _additionally_ for testing is >> >> negative. I grew up with a print statement being the ultimate debugging >> >> tool. A print/debugging statement is added at the time of debugging and >> >> probably removed if the error seems to be fixed. That can lead to a >> >> situation where you do this multiple times. Writing the same as a test (and >> >> that forces you to produce more fine grained code) you will have a saving in >> >> time and a little assurance about regression. Regression debugging >> >> (debugging it again later) is much more time spent because you have to fix >> >> the error _and_ you need to focus again on that problem (which takes most of >> >> the time). So the point in writing tests is not to spend time but to save >> >> time. >> >> >> >> The amount of time one should expect to spend writing tests is less >> >> than the time you need to spend for testing otherwise. :) >> >> >> >> Norbert >

Feb. 27, 2011

Re: [Pharo-project] Good reference on time on unit testing?

by Schwab,Wilhelm K

Let's keep the physical descriptions out of it, ok :) But you have the point: I am looking for published numbers to back up what we all have learned from experience. And it has been surprisingly hard to find. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Peter Hugosson-Miller [oldmanlink(a)gmail.com] Sent: Sunday, February 27, 2011 3:11 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Good reference on time on unit testing? Steven, you're making perfect sense to me, and I think almost everyone here agrees with you. Bill's problem (if I've understood him correctly) is that he needs to convince some pointy-haired-boss-type person, by directing him or her to a well-respected "official" statistic that "proves" what we all know to be true from experience. Sadly, I think it will be hard to find it :-( -- Cheers, Peter On Sun, Feb 27, 2011 at 9:04 PM, Steven Baker <steven(a)stevenrbaker.com<mailto:steven@stevenrbaker.com>> wrote: I've always felt that "test driving" code actually results in negative time spent on "testing". I spend (and everyone I know that tests well does as well) a lot less time writing code test-first than I ever would writing the same code without the tests first. Also, I spend far less time (almost none) manually testing functionality. So TDD results in net negative time difference. (Apologize if I'm incoherent, the cold and flu drugs are strong in this one.) -Steven On Sun, Feb 27, 2011 at 11:51 AM, Norbert Hartl <norbert(a)hartl.name<mailto:norbert@hartl.name>> wrote: > > On 27.02.2011, at 13:58, Schwab,Wilhelm K wrote: > >> Norbert, >> >> Excellent points - I take exception with only one: you assume that all developers test - that is sadly not true. I am involved with a group who seem to think that a handful of tests added at the last minute will somehow magically fix their problems. >> > It seems I wasn't clear on this one. I'm trying to making a point that there is no distinction between "testing" - "no testing" but between "testing" - "writing tests". If you take compilation you test the code for syntax and language quirks. If a developer runs the program he develops than he is testing already. Testing and running a program is the same form that point of view. He takes input parameter and expects output parameter. That is testing. The point is just that developers do it manually and that is not reproducable. So there is no real difference between manual testing all the time and written test case. Only that repeating the testing procedure is boring and therefor supposed to be done by a machine. So if developers could see that the just need to put the work they already doing into a test will ease the work without changing much. They are just changing style and save time. That's it. Talking about 100% test coverage and holistic views about what the perfect testing could be doesn't help. > >> I have no problem arguing that testing (if done well) can/will reduce overall development time; the question is how much of that time one should expect to devote to writing and maintaining unit and acceptance tests? >> > I understand your intention but the view is inapropriate. Coding and testing aren't two things. It is something that belongs together (if you changed coding style). So that's why it is hard to estimate a time that should be spent. To me it is more comparabale to this: We all know collections are great. Imagine someone asking you "Can anyone recommend a good reference on the amount of time one should expect to spend writing code that uses collections?". What would you say? There is no answer. That doesn't mean you can't solve the problem. But you won't solving it by saying "It is 38.345 % of the time". If people don't get it you have to convince and/or teach them. I had several times where I could show the developer that he is gaining time from doing it. That works. Everything else is targeted towards excel manipulators. > > Norbert > > >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Norbert Hartl [norbert(a)hartl.name<mailto:norbert@hartl.name>] >> Sent: Sunday, February 27, 2011 5:41 AM >> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >> Subject: Re: [Pharo-project] Good reference on time on unit testing? >> >> Hi, >> >> On 27.02.2011, at 04:52, Schwab,Wilhelm K wrote: >> >>> Hello all, >>> >>> Can anyone recommend a good reference on the amount of time one should expect to spend writing tests? I will have to be the messenger (will be wearing running shoes just in case...), but I want the message to come from a solid source. >> >> I find that really hard to answer. To me the problem is the question itself. I heard the "..amount of time one should expect to spend writing tests?" so often in companies and I think it was always exactly this phrase. While the question is valid it gives the impression there is something that decucts time from your "normal" development work. So the people that are asking this question are often managing people that have read something about code quality and they want to apply _this_ to their teams. >> The definition over time is troublesome, too. Testing is not easy. Everything you read about testing gives you the impression that everyone knows how to test and that those developers are just too lazy. And that is not true. Most developers I met had problems to see what testing is all about. The don't see interfaces as provable promises etc. So if you tell any of these developers they should spend 1 hour a day in testing than you will get tests that are counter-productive. My favorite example is the one where you have any composite object with an add method. Than the test goes like adding something via the interface and then try to access the internal array and check if it is of size 1. To me it is the same as with documentation. I prefer to have less documentation than useless documentation. >> >> So every developer is testing in some way. You either test and debug on the way in an unstructured form or you write tests. To me writing tests is not an add-on it is a change in working style. From this point of view I would state that the time I need to spend _additionally_ for testing is negative. I grew up with a print statement being the ultimate debugging tool. A print/debugging statement is added at the time of debugging and probably removed if the error seems to be fixed. That can lead to a situation where you do this multiple times. Writing the same as a test (and that forces you to produce more fine grained code) you will have a saving in time and a little assurance about regression. Regression debugging (debugging it again later) is much more time spent because you have to fix the error _and_ you need to focus again on that problem (which takes most of the time). So the point in writing tests is not to spend time but to save time. >> >> The amount of time one should expect to spend writing tests is less than the time you need to spend for testing otherwise. :) >> >> Norbert

Feb. 27, 2011

Re: [Pharo-project] Issue 2820 in pharo: Format Source shortcut key (cmd-r) doesn't work

by pharo＠googlecode.com

Comment #4 on issue 2820 by marcus.d...(a)gmail.com: Format Source shortcut key (cmd-r) doesn't work http://code.google.com/p/pharo/issues/detail?id=2820 Eclipse is free to you, but IBM invested >30 million USD before the first release was made public. It is really difficult to get details right with little/no founding, as this is exactly what people tend to not work on if they can decide themselves on what to work on next.

Feb. 27, 2011

Re: [Pharo-project] Good reference on time on unit testing?

by Schwab,Wilhelm K

Steven, Maybe we all should take some cold meds - you seem very coherent to me; get well soon. The only thing is that after settling on the shorter time to completion, you still spend a fraction of your programming effort/time to get the computer to test your work. It is that fraction that I am trying to quantify. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Steven Baker [steven(a)stevenrbaker.com] Sent: Sunday, February 27, 2011 3:04 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Good reference on time on unit testing? I've always felt that "test driving" code actually results in negative time spent on "testing". I spend (and everyone I know that tests well does as well) a lot less time writing code test-first than I ever would writing the same code without the tests first. Also, I spend far less time (almost none) manually testing functionality. So TDD results in net negative time difference. (Apologize if I'm incoherent, the cold and flu drugs are strong in this one.) -Steven On Sun, Feb 27, 2011 at 11:51 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > On 27.02.2011, at 13:58, Schwab,Wilhelm K wrote: > >> Norbert, >> >> Excellent points - I take exception with only one: you assume that all developers test - that is sadly not true. I am involved with a group who seem to think that a handful of tests added at the last minute will somehow magically fix their problems. >> > It seems I wasn't clear on this one. I'm trying to making a point that there is no distinction between "testing" - "no testing" but between "testing" - "writing tests". If you take compilation you test the code for syntax and language quirks. If a developer runs the program he develops than he is testing already. Testing and running a program is the same form that point of view. He takes input parameter and expects output parameter. That is testing. The point is just that developers do it manually and that is not reproducable. So there is no real difference between manual testing all the time and written test case. Only that repeating the testing procedure is boring and therefor supposed to be done by a machine. So if developers could see that the just need to put the work they already doing into a test will ease the work without changing much. They are just changing style and save time. That's it. Talking about 100% test coverage and holistic views about what the perfect testing could be doesn't help. > >> I have no problem arguing that testing (if done well) can/will reduce overall development time; the question is how much of that time one should expect to devote to writing and maintaining unit and acceptance tests? >> > I understand your intention but the view is inapropriate. Coding and testing aren't two things. It is something that belongs together (if you changed coding style). So that's why it is hard to estimate a time that should be spent. To me it is more comparabale to this: We all know collections are great. Imagine someone asking you "Can anyone recommend a good reference on the amount of time one should expect to spend writing code that uses collections?". What would you say? There is no answer. That doesn't mean you can't solve the problem. But you won't solving it by saying "It is 38.345 % of the time". If people don't get it you have to convince and/or teach them. I had several times where I could show the developer that he is gaining time from doing it. That works. Everything else is targeted towards excel manipulators. > > Norbert > > >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Norbert Hartl [norbert(a)hartl.name] >> Sent: Sunday, February 27, 2011 5:41 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Good reference on time on unit testing? >> >> Hi, >> >> On 27.02.2011, at 04:52, Schwab,Wilhelm K wrote: >> >>> Hello all, >>> >>> Can anyone recommend a good reference on the amount of time one should expect to spend writing tests? I will have to be the messenger (will be wearing running shoes just in case...), but I want the message to come from a solid source. >> >> I find that really hard to answer. To me the problem is the question itself. I heard the "..amount of time one should expect to spend writing tests?" so often in companies and I think it was always exactly this phrase. While the question is valid it gives the impression there is something that decucts time from your "normal" development work. So the people that are asking this question are often managing people that have read something about code quality and they want to apply _this_ to their teams. >> The definition over time is troublesome, too. Testing is not easy. Everything you read about testing gives you the impression that everyone knows how to test and that those developers are just too lazy. And that is not true. Most developers I met had problems to see what testing is all about. The don't see interfaces as provable promises etc. So if you tell any of these developers they should spend 1 hour a day in testing than you will get tests that are counter-productive. My favorite example is the one where you have any composite object with an add method. Than the test goes like adding something via the interface and then try to access the internal array and check if it is of size 1. To me it is the same as with documentation. I prefer to have less documentation than useless documentation. >> >> So every developer is testing in some way. You either test and debug on the way in an unstructured form or you write tests. To me writing tests is not an add-on it is a change in working style. From this point of view I would state that the time I need to spend _additionally_ for testing is negative. I grew up with a print statement being the ultimate debugging tool. A print/debugging statement is added at the time of debugging and probably removed if the error seems to be fixed. That can lead to a situation where you do this multiple times. Writing the same as a test (and that forces you to produce more fine grained code) you will have a saving in time and a little assurance about regression. Regression debugging (debugging it again later) is much more time spent because you have to fix the error _and_ you need to focus again on that problem (which takes most of the time). So the point in writing tests is not to spend time but to save time. >> >> The amount of time one should expect to spend writing tests is less than the time you need to spend for testing otherwise. :) >> >> Norbert >> > > >

Feb. 27, 2011