No meu último post, coloquei alguns frameworks de TDD que mais me interessaram para fazer o porte. Conversando com o Guru de C da equipe (obrigado pela ajuda Leo) acabamos escolhendo o FCTX, um dos motivos é porque simplesmente colocando o seu header você já está apto a trabalhar com ele e segundo não usa nenhuma instrução jump que poderia ser um problema para as plataformas que usamos.
On my last post, I put few TDD’s frameworks that were more interesting to do the port. Talking with Guru of C in the team (thanks Leo) we end up with FCTX, because: first if you simply put its header you already done to work with FCTX and in second it doesn’t use any jump instructions, which would be a problem on ours platforms.
Bom se não falei antes, eu trabalho com POS, eles normalmente tem 2MB de FLASH e 1 MB de RAM para heap, stack e arquivos(existe uma nova geração com muito mais memória), são big e little endian, a maioria trabalha com ARM e são 32 bits, cada fabricante usa um compilador, tem muitas conexões e periféricos, sistemas de arquivos diferentes e gerenciamento de memória (quando tem) diferentes também. Então é mais ou menos como programar na época antes da IBM ter aberto a sua arquitetura de PC.
Sorry if I didn’t told you before, I work with POS, they come with 2MB of FLASH and 1MB of RAM for heap, stack and files (there is a new generation with much more memory), and they are big and little endian. Most of them use ARM and are 32 bits, each manufacturer use a different compiler, they have a lot of connections and peripherals, different file systems and memory managements (when they have) too. In conclusion it’s similar to develop in early days before IBM opens its PC architecture.
Nosso Guru teve que programar a parte da saída do relatório dos testes em arquivo, pois ver isso numa tela de 8Lx21C é cruel demais. E depois de alguns ajustes de memória no FCTX podemos já usar o TDD no POS. O mais importante é que nosso Guru criou uma biblioteca de funções básicas que são praticamente sendo usadas em todos os projetos e essa biblioteca roda no PC, então já podia rodar os testes tanto no PC quanto no POS. (obrigado de novo Leo).
Our Guru had to develop test’s reports into file, because see these reports on a screen with 8 lines by 21 columns is too bad idea. And after a few adjustments on FCTX’s memory’s use, we can run TDD on POS. The most important thing is that our Guru has created a lib of basic functions that are coming to be used in all ours projects and this lib runs on PC, thus I could run the tests on PC and POS. (thanks again Leo)
Eu já usei o FCTX em um POS que rodava LINUX, mas a forma que fiz não ficou muito elegante, o código ficou um sujo e complicado para ler devido às referências de mocks/stubs. Bom não gostando muito do que fiz e acreditando que podia melhorar, conversei com alguns no time e eu consegui bolar algumas idéias para organizar o código:
I already used FCTX on POS with LINUX, but the way that I did it was not elegant, the code was dirty and complicated to read due references of mocks/stubs. Well, I don’t like what I did and I’m convinced that it could be better, I talked to a few in the team and I get few ideas about how to organize the code:
- Qualquer referencia a mocks/stubs devem estar em um .h.
Any reference for mocks/stubs must be on .h. - Uma definição deve ligar/desligar o modo de TDD.
One define must turn on/off TDD’s mode. - Uma definição deve ligar/desligar o modo de TDD no PC.
One define must turn on/off TDD on PC’s mode. - Todas as funções que forem mocks/stubs, em sua definição devem manter os seus nomes originais seguidos de um underscore.
All functions that become mocks/stubs, in their definitions must keep their original’s name followed by a underscore. - Todas as suítes de teste devem estar dentro de uma pasta (TDD) e nome do arquivo fonte deve ser o mesmo do arquivo fonte que está sendo testado seguido de um “_tdd”.
All suites must be inside of a folder (TDD) and the source code’s file name must be the same of the source code’s file name that is being tested followed by “_tdd”.
// on the showLine.h #ifndef _TDD_PC_ #include <manufactHeader.h> //original header #else #include <fakeManufactHeader.h> //few needed definitions copied from original header #endif // this is how the code can call the orginal function or the original one. #ifndef _TDD_ #define displayLine_(text, line, sizeText) displayLine(text, line, sizeTex) #else extern int (*mockDisplayLine)(char*,int,int); // mock definition must be on suite source code. #define displayLine_(text, line, sizeText) mockDisplayLine(text, line, sizeTex) #endif // on the showLine.c #include <showLine.h> int showLine(char* text, int line) { int ret = displayLine_(text, line, strlen(text)); if(ret != strlen(text)) ret = (-1); return ret; }
Até o momento essas regras tem funcionado bem.
Until the moment these rules had been working well.
rafaeltimoteo
