tasklwIP - A Lightweight TCP/IP stack - Tasks: task #7930, Create automatic test cases


You are not allowed to post comments on this tracker with your current authentication level.

task #7930: Create automatic test cases

Submitted by:  Simon Goldschmidt <goldsimon>
Submitted on:  Tue 08 Apr 2008 05:20:02 PM UTC
Category:  None Should Start On:  Tue 08 Apr 2008 12:00:00 AM UTC
Should be Finished on:  Tue 08 Apr 2008 12:00:00 AM UTC Priority:  * 5 - Normal
Status:  Done Privacy:  Public
Percent Complete:  10% Assigned to:  None
Open/Closed:  Closed Planned Release:  None
Effort:  0.00
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:
       No canned response available


( Jump to the original submission )

Fri 12 Nov 2021 09:36:21 PM UTC, comment #8: 

Closing: no need to keep this open... Even if we could have more unit tests...

Simon Goldschmidt <goldsimon>
Project Administrator
Fri 27 Nov 2009 08:05:57 AM UTC, comment #7: 

First unit tests added, mainly for testing tcp ooseq processing.

Simon Goldschmidt <goldsimon>
Project Administrator
Fri 27 Jun 2008 06:22:28 PM UTC, comment #6: 

Great news! But at least for unit tests, I'd prefer them to be under the LWIP_SRC/test/ (LWIP_SRC being the dir where the CHANGELOG file is). This is because it tests the main tree and I hope tests are more 'in sync' with the code if they are in the same tree.

Which such complex tests thomas describes, this is of course another issue, but I'd still prefer them to be 'near' the other tests...

I might go ahead and check in a few unit tests in a few days time to 'get the ball rolling'...

Simon Goldschmidt <goldsimon>
Project Administrator
Fri 27 Jun 2008 12:05:08 PM UTC, comment #5: 

That's great Thomas.  contrib/test sounds like a good place for it, and once we've got something there it will, I hope, get the ball rolling and more may follow.

Kieran Mansley <kieranm>
Project Member
Fri 27 Jun 2008 11:40:30 AM UTC, comment #4: 

The lwIP test harness I was talking about last year has been completed, and I'm working on getting it open-sourced.  It's a black-box (works through socket-api) test framework, implemented using python on a user PC, and interfaces to the embedded target via a network interface.  It's implemented in a fairly general manner, so it's suitable for mass consumption.

This would be a fairly nice complement to the unit-based testing mentioned here.  Do we have a standard location where we're planning on placing these test components?  How about contrib/test?

Also of note, since these are black-box level tests, they do not use the check unit-test framework, which we've standardized on for unit tests.

Thomas Taranowski <taranowski>
Project Member
Tue 15 Apr 2008 11:17:52 AM UTC, comment #3: 

Thank you Erik, I hope be able to try your tests this weekend.

Frédéric Bernon <fbernon>
Project Member
Tue 08 Apr 2008 07:58:09 PM UTC, comment #2: 

> I remember last year when I was stuck with an error in the heap in the 1.2.0 version.. :)

I know, I think I fixed that and I would be happy to see all unit tests pass on this :-)

Simon Goldschmidt <goldsimon>
Project Administrator
Tue 08 Apr 2008 06:54:50 PM UTC, comment #1: 

Ideally with unit tests one tests as small bit of the code as possible, so I think it is a good idea to start with the support code.

I remember last year when I was stuck with an error in the heap in the 1.2.0 version.. :)

Erik Ekman <yarrick>
Project Member
Tue 08 Apr 2008 05:20:02 PM UTC, original submission:  

On lwip-users, we kind of agreed to include test-cases based on the 'check' framework (http://check.sourceforge.net/) into a new CVS folder (src/test ?). (The check framework is also available as package in cygwin!)

Erik has provided 5 example tests for ip.c (e.g. check that UDP/TCP packets are passed to the corresponding layers, check that unknown IP protocol leads to call to ICMP module, ...) available at http://kryo.se/test-1.3.0.tar.gz (Erik, I didn't know if we can post them here).

I opened this task mainly to talk about which tests we need. I think the most important part is to check the "support modules" (mem, memp, pbuf, sys, ...). When this works, we can work on tests for the protocols (as they make heavy usage of the "support modules").

Any preferences?

Simon Goldschmidt <goldsimon>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by kieranm (Posted a comment)
  • -email is unavailable- added by taranowski (Posted a comment)
  • -email is unavailable- added by fbernon (Posted a comment)
  • -email is unavailable- added by yarrick (Posted a comment)
  • -email is unavailable- added by goldsimon (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-11-12 goldsimon StatusNone => Done
        Open/ClosedOpen => Closed
    2010-01-10 goldsimon Percent Complete0% => 10%

    Back to the top

    Powered by Savane 3.9