On 22 August 2011 22:54, Nicolas Cellier <[email protected]> wrote: > 2011/8/22 Stéphane Ducasse <[email protected]>: >>>> 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 >> > >
