Basically the test confirms that the long lasting scraping operation returns the expected result . As you suggested let me take a look at Zn
On Jan 26, 2018 10:31, "Sven Van Caekenberghe" <s...@stfx.eu> wrote: > > > > On 26 Jan 2018, at 16:16, Andrei Stebakov <lisper...@gmail.com> wrote: > > > > How do you handle forked operations from TestCase point of view, when > the test expects a value to assert from an asynchronous operation? > > tests typically run sequential & synchronous, it is hard to work with them > otherwise (to debug them, to handle there failures). > > it is of course possible to write much more complex tests, doing all kind > of magic, but well, they are complex and require experience. > > many Zn test run http client against http servers, you could look there > for examples. > > what is your exact scenario or use case ? > > > On Jan 25, 2018 10:41, "Andrei Stebakov" <lisper...@gmail.com> wrote: > > Thanks, Sven, got it > > > > On Jan 25, 2018 10:36, "Sven Van Caekenberghe" <s...@stfx.eu> wrote: > > Hi Andrei, > > > > > On 25 Jan 2018, at 16:26, Andrei Stebakov <lisper...@gmail.com> wrote: > > > > > > I have written some code that has a deep nested loop of calling > ZnClient>>get. > > > In the loop I also execute Transcript>>show but I can only see the > transcript output after a few seconds when the loop is finished. During all > that time while the loop is busy the UI is also unresponsive. > > > Is there a way to execute code in some sort of asynchronous way? > > > > The problem is not specific to using ZnClient, it is with every loop you > execute in the UI thread: the Transcript output is not updated (as it is > the UI thread itself that has to do the drawing). > > > > For example, try > > > > 1 to: 10 do: [ :i | Transcript crShow: i. 5 seconds wait ]. > > > > The solution is to run you long running code in another thread, like this > > > > [ 1 to: 10 do: [ :i | Transcript crShow: i. 5 seconds wait ] ] fork. > > > > HTH, > > > > Sven > > >
