[Oisf-devel] Coding style improvement proposal
Jason Ish
lists at unx.ca
Tue May 12 15:31:16 UTC 2015
On Tue, May 12, 2015 at 9:05 AM, Eric Leblond <eric at regit.org> wrote:
> Hello,
>
> As some of you know, I don't like unittests. And when I see things like:
>
> int SMTPProcessDataChunkTest02(void){
> char mimemsg[] = {0x4D, 0x49, 0x4D, 0x45, 0x2D, 0x56, 0x65, 0x72,
> 0x73, 0x69, 0x6F, 0x6E, 0x3A, 0x20, 0x31, 0x2E,
>
> I start to think I'm right. The raw data are completely unreadable by
> normal human being o you can't guess what is done when you need to fix
> the unittests^W code after some changes.
>
> IMHO, we should have on top of these raw data a textual representation
> of the byte fields in comment. Like this is done somewhere else in the
> app-layer-smtp.c file:
>
> int SMTPParserTest14(void)
> {
> /* 220 mx.google.com ESMTP d15sm986283wfl.6<CR><LF> */
> static uint8_t welcome_reply[] = {
>
> What do you think ?
I agree. Here's how I'm doing it for some of the DNP3 unit tests...
uint8_t request[] = {
/* Link header. */
0x05, 0x64, 0x1a, 0xc4, 0x02, 0x00, 0x01, 0x00,
/* CRC. */
0xa5, 0xe9,
/* Transport header. */
0xff,
/* Application layer. */
0xc9, 0x05, 0x0c, 0x01, 0x28, 0x01, 0x00, 0x00,
0x00, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00,
/* CRC. */
0x72, 0xef,
/* Application layer. */
0x00, 0x00, 0x00, 0x00, 0x00,
/* CRC. */
0xff, 0xff,
};
It will requires a quick glance to the struct sometimes to know whats
what, but much better than a big old blob of hex IMO.
More information about the Oisf-devel
mailing list