[SqNOS] New release: RTL8139 support, TCP/IP "working", native improvements

Stef dijo:
> are you writing tests for SqueakNet?
> Because this is a cool project and with tests we could really build  
> on top of it.
>
>  
    Hi Stef!

    The truth is that Luciano is doing all the work in NetSqueak. And
yes, he's doing lots of tests (lots and interesting). Let me copy here
he's last commit log to http://www.squeaksource.com/Net.html. For every
thing he does, he does tests. The last thing he implemented for testing
is the RealisticLoopback InternalNetworkDevice. A subclass of Loopback
which implements drops, corruption and delays. To test how the stack
behaves in this cases.
    On the other side, for SqueakNOS I'm not writing no tests. I don't
really know how to write tests for the HardwareDevices, but the truth is
that I have not yet felt the magic of tests, so I'm not pushing it too
hard... mea culpa.

    ok, the commit log for your pleasure:

Name: Net-len.13
Author: len
Time: 1 August 2006, 2:02:21 pm
UUID: dcfbc174-bcdb-4690-8af7-b46ab4704681
Ancestors: Net-len.12

- Implemented delayed ACKs in TCP.
- New tests for TCP.
- Timers now are working.
- Refactored InterfaceConduit/ProtocolStack... the two of them are now
one: NetInterface. I don't know yet if this is good enough, but I had to
do this change because I needed to start and stop timers (TCP, IP
reassembly and ARP timers), and the same object that understands #up and
#down (the interface) and manages the process that handles incomming
packets seems to be the right object to start and stop timers. All
processes that are required for the networking stack are started and
stopped sending #up and #down to the network interface.

Excellent!
It is cool to see people having fun like that and also doing it the  
right way :)

Stef

Richie!

>    On the other side, for SqueakNOS I'm not writing no tests. I don't
> really know how to write tests for the HardwareDevices, but the truth is
> that I have not yet felt the magic of tests, so I'm not pushing it too
> hard... mea culpa.

That's really too bad! Stop working that way and start writing tests. You
will love them!

/Leandro


----- Original Message -----
From: "Gerardo Richarte" <[hidden email]>
To: <[hidden email]>; <[hidden email]>;
<[hidden email]>
Sent: Wednesday, August 02, 2006 12:11 PM
Subject: [SqNOS] New release: RTL8139 support, TCP/IP "working",native
improvements

Dear Richie,

I think that it is fair enough to write some code without tests in order
to get things working, and I understand that it may be difficult to
write tests for hardware devices.

The way that we talk about testing does not really capture the true
nature and benefits of "test first" coding. There is an article by Dave
Astels about this, (and a podcast on the "Agile Toolkit" series) in
which he suggests changing the wording that we use to talk about tests,
and then it makes a lot more sense and can begin to drive  and support
the way we develop. This approach has been called Behaviour Driven
Development, and I think it may be worth a look for you.

Dave talks about specifications. First defining the working context.

context( initial state, hardware is not present at all )
specification( auto discover should not find hardware )
{
expectation: do auto discover should raise NotFound  
}
specification( attempt to send data should raise error )
{
expectation: send data should raise error
}

Dave has wrote a Smalltalk version of rSpec (ruby spec), called sSpec, a
month or two ago. I wrote spec.js for javascript. I believe that Dave
has it working and available in VisualWorks. It would be great if
someone just did the last bit of the port into squeak.

Another aspect of the specification frameworks is the extensive use of
Mock objects, and these beauties could be used to stand in for bits of
hardware in your tests. You can preload a generic mock object with the
expected behaviours and responses and pass it in instead of the real thing.

Like many will tell you tests rock, but thinking in terms of
specification of expected behaviour is a good way of thinking a problem
through. The use of a framework such as sSpec allows these thoughts to
be penned as an executable specification.  Which is really  cool... well
I thought so.

best regards

Keith








       
       
               
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html

Hi keith


On 4 août 06, at 01:29, Keith Hodges wrote:

> Dave has wrote a Smalltalk version of rSpec (ruby spec), called  
> sSpec, a month or two ago. I wrote spec.js for javascript. I  
> believe that Dave has it working and available in VisualWorks. It  
> would be great if someone just did the last bit of the port into  
> squeak.

I browsed a bit the design card and I'm trying to understand the  
difference between test and spec.
Can you explain us a bit?

Thanks

stéphane ducasse wrote: There is not much difference between a spec and a test. However the
wording is aimed to encourage a change of thinking.

 From "I coded this does it work" to "In this situation I would like
this to happen". The penny did not drop for me until I worked through
the example here.

http://rspec.rubyforge.org/tutorials/index.html

best regards

Keith


               
____________________________________________________
 
Yahoo! Photos is now offering a quality print service from just 7p a photo. http://uk.photos.yahoo.com