On Tue, Feb 4, 2014 at 10:01 AM, Goubier Thierry <[email protected]>wrote:
> > > Le 04/02/2014 09:48, Usman Bhatti a écrit : > >> >> >> >> On Tue, Feb 4, 2014 at 9:29 AM, Goubier Thierry <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> Le 04/02/2014 09:23, Usman Bhatti a écrit : >> >> >> >> >> Yes, I use that already with Glamour and Roassal, and other morph >> widgets that I have. >> The harder part for me so far is responding to dialog boxes e.g. >> answer >> the user questions automatically and once I have that, I'd be >> able to >> completely test my current set of UIs automatically. >> >> >> What about writing a Shim over the dialog creator with a catalog of >> predefined answers that could be picked by each dialog creation? >> When calling a dialog, we're usually going through a factory >> interface usually. >> >> >> I do not know what is a Shim. >> > > From Wikipedia: > > In computer programming, a shim (from shim) or shiv is a small library > that transparently intercepts an API and changes the parameters passed, > handles the operation itself, or redirects the operation elsewhere. Tx for this info. I was not aware of it and it is surprising for me because half of my doctoral thesis was about AOP and related concepts, and Shim seems to be a very similar concept, in its definition, to AOP. > > > Sometimes, we would like to provide our own answers to the dialogue to >> see if the tests pass in different configurations (e.g. when we have two >> or more checkboxes, to see if we get different results selecting >> different boxes). >> >> Or may be we can start with a simpler solution and then evolve towards a >> completely customizable one. >> > > My simple approach would be : > > in normal code, instead of calling UIManager directly as in: > > UIManager default chooseFrom: aCollection title: aString withCRs. > > use a shim (self class myUIManager ....). In the test case, setup so that: > > `self class myUIManager` returns a shim over UIManager capturing the > chooseFrom:title: and containing a dictionary with 'title' -> value to > choose. You preload the shim with the right answers and the keys for the > shim to find to which dialog this refers (it could be ordered: answer for > first dialog, answer for second dialog, etc...). The shim, instead of > creating the dialog, returns the value it already has (or an error if it > hasn't, which will help you fill the needed values !). > > For stuff not related to dialogs you are using the shim for, you can just > do a passthrough (i.e. UIManager default perform: ) which can even be > handled automagically via doesNotUnderstand:. > > As you can see, there isn't much to it. I see and I've been achieving it in another way. aClass >> export fileRef := UITheme builder fileSave: 'Choose a file' extensions: #('txt') path: nil. fileRef isNil ifFalse: [ self exportOn: fileRef writeStream ] Instead of testing the method export, I test exportOn: with a stream as a parameter. What I am thinking is that, with this approach, we are not testing all the execution paths in the method export. But then, with a Shim, we will not be testing that path either. Usman > > > 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 > >
