Разработка через тестирование со скрытыми переменными и методами на C

Есть ли правильный способ эффективно использовать TDD (разработка, управляемая тестированием) для частных переменных и функций?

Я тестирую новый кольцевой буферный модуль. Параметры буфера хранятся в структуре. Эти элементы структуры должны быть закрытыми, поскольку клиенту не нужно к ним прикасаться. НО из-за сокрытия членов тестирование становится намного сложнее. Если формат структуры является общедоступным в заголовке, я могу напрямую проверить, указываю ли я на массив хранения, что мой индекс чтения правильный, что мой индекс записи правильный и т. Д. Если частный, я могу только проверить интерфейс, что мне, очевидно, нужно сделать, но проверка скрытых функциональных возможностей кажется медленной и неэффективной.

buf.h

typedef struct circBuf circBuf_t;

buf.c

struct circBuf {
    privateMember_1;
    ...
    privateMember_n;  
};

Должен ли я включить шпиона в свою тестовую функцию? то есть:

test_buf.c

#include "buf.h"      

struct spy_circBuf {
    privateMember_1;
    ...
    privateMember_n;
};

void test_circBufInit(void) 
{
    circBuf_t * p_testCircBuf;
    struct spy_circBuf * p_spy;

    p_testCircBuf = CircBuf_Init (initVar_1, ...);

    p_spy = ((struct spy_circBuf *)p_testCircBuf);

    TEST_ASSERT_EQUAL(p_spy->privateMember_1, initVar_1);
}

Есть ли лучший способ сделать TDD для частных переменных и функций?


c unit-testing struct tdd hidden-variables
person jaypee    schedule 05.03.2014    source источник
comment
См. googletesting.blogspot.com/2013/03. / Если вы не можете проверить состояние, проверьте взаимодействие вашего объекта с другими объектами.   -  person Carl Manaster    schedule 05.03.2014

Ответы (1)


arrow_upward
1
arrow_downward

TDD предназначен для тестирования внешнего поведения вашего класса, а не внутренней реализации. Если ваши тесты будут смотреть на внутреннюю реализацию, они будут хрупкими и могут сломаться, если детали реализации изменятся. Это отпугнет вас от рефакторинга и улучшения кода.

TDD также подчеркивает, что вы пишете каждый тест перед написанием необходимого производственного кода. Это помогает избежать тестирования реализации, потому что вы пишете тест для реализации, которой еще не существует. Это побуждает вас подумать о желаемом поведении вашего класса и написать тест, чтобы проверить это поведение.

person Mike Stockdale    schedule 06.03.2014
comment
спасибо Майк. это имеет смысл и находит отклик. Я определенно вижу, как взгляд на внутреннее устройство подавляет желание рефакторинга. плюс, если будут протестированы все угловые случаи, внутренняя реализация будет хорошо протестирована, и я могу свободно изменять / рефакторинг, и меня интересует только api. мне это нравится. и я могу видеть, как изменение фокуса на поведение модуля от поведения реализации является идеальным, потому что сначала мы должны сосредоточиться на том, что делает модуль, а не только на том, как он это делает, и застрять на нерелевантном пути разработки. - person jaypee; 07.03.2014