We should have a policy on this. I've been guilty of writing new features without tests too. It's bad enough we have to deal with untested legacy code, but to replace key parts of the system with untested code doesn't seem like such a good idea. In particular, the latest Spec refactoring broke a lot of the UI. It's a validation of how well it's been received. It has become a crucial part of much of the IDE. At various points in 3.0 the ChangeSorter, Versionner, and SliderModel have been broken, to name a few, and I get mysterious and sudden, often image wrecking, DNUs that appear, like TextModel>>#asText. It's made it very hard to work, especially when the compiler, RPackage, etc are changing (and sometimes breaking) at the same time. ----- Cheers, Sean -- View this message in context: http://forum.world.st/TDD-in-Core-tp4735378.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
+1 to just add things with appropriate tests. in the case of Spec in particular, the problem is that is really hard to have UI testing :( Also⦠sometimes you break backward compatibility, thatâs inevitable⦠and is ok if is for the best (like in the case of Spec⦠it was to gain ui platform independence). but anyway, I do agree that we need to raise our acceptance criteria :) Esteban On 09 Jan 2014, at 12:22, Sean P. DeNigris <sean@clipperadams.com> wrote:
We should have a policy on this. I've been guilty of writing new features without tests too. It's bad enough we have to deal with untested legacy code, but to replace key parts of the system with untested code doesn't seem like such a good idea. In particular, the latest Spec refactoring broke a lot of the UI. It's a validation of how well it's been received. It has become a crucial part of much of the IDE. At various points in 3.0 the ChangeSorter, Versionner, and SliderModel have been broken, to name a few, and I get mysterious and sudden, often image wrecking, DNUs that appear, like TextModel>>#asText. It's made it very hard to work, especially when the compiler, RPackage, etc are changing (and sometimes breaking) at the same time.
----- Cheers, Sean -- View this message in context: http://forum.world.st/TDD-in-Core-tp4735378.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
+1 So, what do we do to make it happen? Doru On Thu, Jan 9, 2014 at 12:28 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
+1 to just add things with appropriate tests.
in the case of Spec in particular, the problem is that is really hard to have UI testing :( Also⦠sometimes you break backward compatibility, thatâs inevitable⦠and is ok if is for the best (like in the case of Spec⦠it was to gain ui platform independence).
but anyway, I do agree that we need to raise our acceptance criteria :)
Esteban
On 09 Jan 2014, at 12:22, Sean P. DeNigris <sean@clipperadams.com> wrote:
We should have a policy on this. I've been guilty of writing new features without tests too. It's bad enough we have to deal with untested legacy code, but to replace key parts of the system with untested code doesn't seem like such a good idea. In particular, the latest Spec refactoring broke a lot of the UI. It's a validation of how well it's been received. It has become a crucial part of much of the IDE. At various points in 3.0 the ChangeSorter, Versionner, and SliderModel have been broken, to name a few, and I get mysterious and sudden, often image wrecking, DNUs that appear, like TextModel>>#asText. It's made it very hard to work, especially when the compiler, RPackage, etc are changing (and sometimes breaking) at the same time.
----- Cheers, Sean -- View this message in context: http://forum.world.st/TDD-in-Core-tp4735378.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com "Every thing has its own flow"
Le 09/01/2014 12:28, Esteban Lorenzano a écrit :
+1 to just add things with appropriate tests.
in the case of Spec in particular, the problem is that is really hard to have UI testing :(
I'd say that Pharo makes it easy to do UI testing. Look, you can test an app by opening a window, eventing it and closing it before the user has even seen the window on screen ? But yes, GUIs have a lot of functionalities and hence are hard to test.
Also⦠sometimes you break backward compatibility, thatâs inevitable⦠and is ok if is for the best (like in the case of Spec⦠it was to gain ui platform independence).
but anyway, I do agree that we need to raise our acceptance criteria :)
One issue is that even the current test suites do not give me confidence. I just did a refactoring of the announcement stuff in Morphic (12531 and 12598), all tests are green but honestly I know those tests are not testing enough code. (in short, it's : help me for 12598! I'll push a slice and I'd really like people using Nautilus and other GUI heavy stuff to pound on it and report issues) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
EstebanLM wrote
in the case of Spec in particular, the problem is that is really hard to have UI testing :(
I don't mean to pick on Spec. I'm very grateful for all the work Ben is doing. It's just that it has become essential to getting any work done in Pharo, and is undergoing a lot of changes, and in my recent 3.0 experience is causing a lot of pain. And while some UI testing is hard: - it's much easier in Pharo than anywhere else, since widgets = Morphic = just another part of the live, turtles all the way down environment - see the UI testing stuff I did which is in core and let's you simulate clicks, menu selections, etc - some of the breakage did not even require UI interaction to test. For example, for SliderModel, this simple statement, which doesn't even open the UI, would've caught the bug: "SliderModel new buildWithSpec", but there are only 7 tests to cover all of Spec, none of which mention SliderModel. We haven't even felt the pain of hard stuff because we've all (of course myself included) created a culture where testing is secondary or non-existent. And of course I'm only speaking about testing, not backward-compatibility. Although, while we're on the subject, the changes with this last iteration were significant enough to necessitate more communication. For example, you can no longer return a Morph instead of a model from a Spec accessor, but instead have to convert to some kind of adaptor. How the heck could I know that?! I had to dig through examples of Spec tools in the image to see how it is now done⦠more time lost... In working with 3.0 recently, a fair amount of my time (it feels like most, but I may be exaggerating) has been spent chasing bugs on untested, undocumented features, which is why I resisted porting (see recent list thread). Don't get me wrong⦠I happily pound on our new versions close to release time and fix as much as I can. And I understand that some of this is inevitable. But when these problems are caused by *new* features, what could've been caught by the code-writer via tests will take me 10x as long to: 1. file a bug 2. mail the list 3. investigate through unfamiliar code 4. make the fix 5. wait for review ⦠etc⦠you get the idea My goal is to discover the path toward maximum effectiveness, and IMHO we have swung a bit too far toward "throw it in the image and wait for the bug reports", especially for critical components, when a bit of testing and documentation could free us all to work on other important parts of the system. Thanks for listening... ----- Cheers, Sean -- View this message in context: http://forum.world.st/TDD-in-Core-tp4735378p4735482.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (4)
-
Esteban Lorenzano -
Goubier Thierry -
Sean P. DeNigris -
Tudor Girba