On 22 August 2011 22:54, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2011/8/22 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Nicolas
From I understood this is a fix to fix another problem that conflicted with some hidden logic. Apparently Squeaksource could save anempty file and you could not upload a new version. So a fix "appeared" but it broke another aspect.
Now clearly using an old image with an old vm with an old version of Seaside and thousands of files and lukas leaving for google led to the fact that indeed the process is not good. Shit happen. Now this is why we want SmalltalkHub and I hope that we will have process to upgrade.
Stef
Sure, we have the right to make mistakes. That's just the way to announce it that would raise more questions than answers in the mind of an annoying client like me ;) (to be polite)
Nicolas
I understand but this was reality and we should improve and structure our processes. Squeaksource is born before pharo and the current tools we use. So I know that we will be far more picky on SmalltalkHub :)
Sure, having the right to make mistakes implies the obligation to guard against mistakes. How do you write tests for all the edge cases (like simulating network load/failures, etc...) ?
In my previous day job I wrote a SIP stack, so I had to worry about some of these things. Some kinds of failure _are_ testable: mock out the network layer, and inject fake errors. This allows you to immediately test a whole range of errors: an unreachable server, a server that disappears mid-connection, broken DNS, intermittent failures, ... By "mock" I mean one of two things: a classic objects-only layer with an API to which all network stuff talks, or a server that allows you to "supply" misbehaviour. Obviously the former is a lot faster, and allows you to create unit tests for your bottom-most, network-facing layer of your application. Michael Nygaard's "Release It!" describes a test harness on pp 125-128: a server intentionally designed to do all manner of nasty things - accept connections but not return data, return data extremely slowly, refuse connections, fail to ACK, ... Each kind of bad behaviour runs on a separate port, allowing you to just place the test harness in your QA environment and potentially have multiple services under test talk to it. frank
Nicolas
Stef