Re: [cpp-netlib-devel] Some code already up in subversion

[Dean M. B. <mik...@gm...>]

Hi Glyn!

On 5/20/07, Glyn Matthews <gly...@gm...> wrote:
> Dean,
>
> On 20/05/07, Dean Michael Berris <mik...@gm...> wrote:
> > I'm developing this using the Test Driven Development approach, where
> > I write the tests first (in libs/network/test) then make the tests
> > "run green" by adding new functionality and/or refactoring.
>
>
> That's a good approach, I agree.  But I ran the tests immediately and they
> didn't run.  I used gcc 4.1.2 and intel icc 9.1 on suse linux 10.2.  I was
> able to run the tests by changing the following lines to:
>
> network/message/wrappers/headers.hpp:35
> return
> headers_wrapper<Tag>::_message.headers().equal_range(key)
>
> network/message/wrappers/headers.hpp:39
> return headers_wrapper<Tag>::_message.headers().count(key)
>
> And I also replaced the local class "tags" in the first test case.
>

Good catch! I haven't tested on Linux just yet, been running the tests
in Windows using MSVC 8. :)

> For the tests it might be better to include individual headers (e.g.
> message.hpp instead of network.hpp).  Also, I'm a bit worried that the
> header guards could potentially clash (for example, you have used
> __NETWORK_HPP__ and I've seen that defined in other headers that I've come
> across).  These are minor things, however.
>

Yeah, somehow I'd have to rethink the include guard names... I've
found myself doing that from habit, naming the include guard based on
the file name. :D We could change this by adding some uniqe prefix or
suffix... Should be simple enough to do though. :)

> How do you intend to structure the tests?  Will you test the different
> layers that you have described distinctly?  Have you given any thought to
> how to test between layers?
>

Actually I use the unit tests for specifying interface and behavior.
The approach is to do testing at various levels, and this is the
lowest.

The next level of tests would be integration tests, where multi-layer
operations are used and verified to be working according to behavioral
expectations. These would go into a different subdirectory inside of
libs/network/test -- something like libs/network/test/integration.

Then there'd have to be some sort of mock testing at the protocol
level. I think we can write testing harnesses that other people can
use, because I know I've done this before in another project. ;)

We can structure the tests in a different way if this approach seems
cluttered and unorganized... I just tend to put unit tests into a
single place and name them differently to distinguish what I want them
called. :)

> I have to say I'm new to boost development, should I update any changes
> myself or do I have to pass them by you first?
>

Please update any changes as long as the tests are green. Again, if
we're going to be introducing new functionality/code, we need a unit
test for it first. :D

Any "major" changes would have to be discussed among ourselves though. :)

> Kind regards,
> Glyn
>

Thank you very much Glyn! :)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459