February 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] PharoCasts has a new skin

by laurent laffont

Thanks to Claire & Patrick Barocca, PharoCasts now has its own skin and a nice logo ! http://www.pharocasts.com/ Laurent

Feb. 27, 2011

Re: [Pharo-project] shout for pharo 1.2: Please help.

by StÃ©phane Ducasse

Ok For me I just wanted to check if I can load shout. Now it is just breaking on Dev Toolset>> SHWorkspace open. I still do not understand how the correct version of shout was loaded before. Since Pharo was referencing 1.2.1 which was referencing jannik old version and the one with the fix of benjamin was not loaded. So I should adapt the baseline to load the correct test in 1.2.2 The problem is that testing all the setup takes 35 min. Stef > So Stef, I looked at ConfigurationOfPharo-StephaneDucasse.139 and I noticed that you commented out some package specs for 1.2-beta2 ... you need to be aware that commenting them out does not prevent those packages from being loaded .... > > To make structural changes you need to remove the package spec from 1.2-beta2 _and_ remove the package from 1.2-baseline. > > The specification for Shout Tests in 1.2-beta2 specifies the mcz file to load. By commenting out the spec and leaving the spec in 1.2-baseline you are telling Metacello to load the latest version of the Shout Tests package.. > > Since 1.2-baseline is already shared by multiple versions, one way to remove Shout Tests for version 1.2-beta2, is to create a 1.2-beta2-baseline that does not include Shout Tests... > > You comment says that you don't know which version of the Shout Tests to load, but by looking at 1.2-beta2-baseline, Shout Tests is referencing the same project as Shout with a different load directive so it is correct to use the save version as Shout. > > In a normal case I would recommend that you use the validator to look at the configuration and fix those issues, but there _are_ a number of validation issues with ConfigurationOfPharo already (which depending on what other changes you have made might actually be contributing to the problem ... There were also validation issues ConfigurationOfShout ... so you might have hit a "perfect storm" of validation issues .. > > I have merged your changes into my working copy and I'll be doing a test load shortly so perhaps I'll be able to observe some of the problems first hand .. > > Dale > > On Feb 27, 2011, at 8:30 AM, StÃ©phane Ducasse wrote: > >> Ok >> I do not understand how it loaded before because >> I got a duplicate instance warning raised (even if the class loaded was empty - I do not get it) >> So I remove the empty package, fixing the version and the baseline... >> >> Now I have the decompiler popping windows.... problem >> Today this is tedious. >> For a fix of 1 min I already spent 2 hours to try to load a configuration. >> >> Stef >> >> >>> Stef, >>> >>> I will try to take a look at your issue today along with testing out the configuration fixes I have pending ... both Pharo and Shout had configuration issues, but I can't say that your particular issue is related ... yet. >>> >>> Dale >>> >>> On Feb 27, 2011, at 7:57 AM, StÃ©phane Ducasse wrote: >>> >>>> Hi guys >>>> >>>> I modified >>>> >>>> version 1.2.1 of ConfigurationOfShout to load my version >>>> Shout-sd.101 (apparently lot of comments were removed between Benjamin.100 and Benjamin.101 - strange) >>>> >>>> >>>> In ConfigurationOfPharo there is >>>> >>>> project: 'Shout' with: '1.2.1'; >>>> >>>> >>>> Now in ConfigurationOfShout there are >>>> >>>> version122: spec <version: '1.2.2' imports: #('1.1-baseline')> spec for: #common do: [ spec blessing: #development. spec author: 'Francisco Ortiz PeÃ±aloza'. spec description: 'Shout Changes for 1.2 using new SmalltalkEditor'. ]. >>>> >>>> >>>> version121: spec >>>> <version: '1.2.1' imports: #('1.1-baseline')> >>>> >>>> spec for: #common do: [ >>>> spec blessing: #development. >>>> spec author: 'Stephane Ducasse'. >>>> spec description: 'Shout for 1.2'. >>>> ]. >>>> >>>> >>>> When I load the latest stable of Pharo >>>> >>>> ((Smalltalk globals at: #ConfigurationOfPharo) project version: #stable) load >>>> >>>> I get an error due to a duplicate (probably the instance variable of pluggableShout.....). >>>> Probably loading the wrong package. >>>> >>>> So I do not know what to do and lost my time. >>>> >>>> Stef >>> >>> >> >> > >

Feb. 27, 2011

Re: [Pharo-project] comments comments comments again

by Francois Stephany

I find it frustrating to load a package and to have no clue where to start. The user must scan the classes and guess which one are 'entry points'. Class comments does not help there. For a user perspective I would prefer to have a HelpSystem indicating where to start. Now I guess class comments are useful when you're hacking/refactoring. On 27/02/11 19:49, Mariano Martinez Peck wrote: > > > On Sun, Feb 27, 2011 at 4:18 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > > Hi > > why can we put comment in class comment? > For example I worked on fixing 1.2 and now I want to execute the > configurationOfPharo and no magic invocation.... > JUST A FUCKING EMPTY class comment as usual. > > > So again I feel like an idiot and I'm trying in the dark. You have > NOT A SINGLE REASON NOT TO PUT COMMENT! > One of these days I will hack the system to break the load when a > class as no comment. > > > I was the original author of such class. And yes, I don't write class > comments. I am not use too, usually because: > > - I almost don't find it use > - The browser doesn't help me to see class comments > - Who can guess that under a '?' there are class comments? I discovered > that YEARS after I was already using Smalltalk > - I prefer writting/reading a TestCase for such class (I know it is not > the same as class comments, but it helps). > - I prefer looking at senders/references to such class > - When class comments are long, the browser is FUCKING slow to write > > Even more, in this case, what would you write for example? > ConfigurationOf* are just Metacello Configurations. What would you need > to know about that despite of Metacello? If you know Metacello, you > should know how to query the configuration and get all the things you > want, like groups, packages, etc > > > So now after randomly trying.....I get a nice DNU. > > > But do you think that could be fixed just because of having class comments? > > Apparently my time is not worth anything.... > > So if you want to see if my fix works. Give a try I will not and if > what I did break, may be I will have a look or may be not > because no time for that after. > > > And BTW do not put any comment, it feels much cooler that way. > > Stef > > >

Feb. 27, 2011

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

by Steven Baker

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 Peter Hugosson-Miller

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 Steven Baker

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 Norbert Hartl

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

Cesar, Alexandre, Thanks. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br [csrabak(a)bol.com.br] Sent: Sunday, February 27, 2011 2:24 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Good reference on time on unit testing? Yes, thus for Bill this mean that for amount of time already expended you need about the same amount for writing tests. YMMV if the cyclomatic complexity (or similar metric) is higher of lower than 'average' programs. In a more commercial scenario, you can cite Gartner's Research Note SPA-19-3568 where they put 10 to 15% of total development time for unit testing and 10 to 15% time for system [integration] testing. These numbers vary a lot, but you can find good references in Software Engineering books or periodicals. HTH -- Cesar Rabak Em 27/02/2011 11:28, Alexandre Bergel < alexandre.bergel(a)me.com > escreveu: Robert Martin said in his book that one should spend ~50% of its time writing tests. Cheers, Alexandre On 27 Feb 2011, at 00: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. > > Bill > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 27, 2011

[Pharo-project] [COTDC] 20 - Loader

by laurent laffont

Today: Loader Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

Feb. 27, 2011

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

by csrabak＠bol.com.br

Yes, thus for Bill this mean that for amount of time already expended you need about the same amount for writing tests. YMMV if the cyclomatic complexity (or similar metric) is higher of lower than 'average' programs. In a more commercial scenario, you can cite Gartner's Research Note SPA-19-3568 where they put 10 to 15% of total development time for unit testing and 10 to 15% time for system [integration] testing. These numbers vary a lot, but you can find good references in Software Engineering books or periodicals. HTH -- Cesar Rabak Em 27/02/2011 11:28, Alexandre Bergel < alexandre.bergel(a)me.com > escreveu: Robert Martin said in his book that one should spend ~50% of its time writing tests. Cheers, Alexandre On 27 Feb 2011, at 00: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. > > Bill > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 27, 2011