Concept of TDD Test Driven Development Test driven

Concept of TDD Test Driven Development Test driven development concepts required for embedded systems (Lab. 1) 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 1

Tackled today n Why test? n Difference between n TLD – Test Last Development n TDD – Test Driven Development (Test First Development) n Examples used in Lab. 1 marking n The required program for Lab. 1 involves minor modification of the functions developed in the first assignment. n More details on the testing process n Design of custom TESTs and ASSERTS 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 2

“Normal” code development n The customer talks to you n You think you have an idea of what you need to develop and what the expected results will be n You develop the code, hopefully in an incremental fashion n You design some UNIT tests to see if the code works n and then remove the test code before delivery as it gets in the way of running the program n You develop new tests when the code comes for maintance 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 3

“Better” code development n The customer talks to you n You think you have an idea of what you need to develop and what the expected results will be n You develop the code, hopefully in an incremental fashion n You design some UNIT tests to see if the code works. n n These tests are designed so that they don’t interfere – with the running of the code The test environment is designed for automatic running of the tests n You REUSE the tests whenever you make changes in the code or when the code comes for in maintance 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 4

New ideas – Test Driven Development n The customer talks to you PROVIDES SOME TESTS THAT WILL WORK WHEN YOU PROVIDE THE CORRECT CODE – CUSTOMER TESTS You think you have an idea of what you need to develop and what the expected results will be. n SINCE YOU KNOW THE EXPECTED RESULTS, DESIGN THE TESTS You develop the simplest code to satisfy the tests n These tests are designed so that they don’t interfere – with the running of the code n The test environment is designed for automatic running of the tests Once the code is running, you “refactor” and check that the tests still run You REUSE the tests whenever you make changes in the code or when the code comes for in for maintance n n n 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 5

Test Driven Development with Embedded Systems Many issues to be resolved include n Do you have the skills to be able to design tests? Many people don’t get above an elementary level here – job prospects n Embedded Systems are “real-time-systems”. n Can you design automated tests that don’t interfere with the running of the system? n Embedded Systems have limited memory. n Can you designs automated tests that don’t “hog” all the memory? n Embedded Systems are a mixture of hardware and software components. n Can you design tests that handle these different components? n Embedded Systems hardware often “does not exist” and must be evaluated using architectural (highly accurate) simulators n Will the tests work in the simulator and on the real system? 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 6

VDSP-Lite n This is a version of an open source product called CPP- Lite n We have modified the code to work for ENCM 415 for the Analog Devices ADSP-BF 533 Blackfin Processor n n n This has special features including a BTC – background telemetry channel – designed for high speed communication Going to demonstrate how to test for the software needed in Lab. 1. This software will be needed for all Labs, whether they involve hardware or software. 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 7

Lab. 1 Part 1 – Requirements on Web Build a file main. cpp with C++ stubs for the following programs int main(void); char *Hello. World(const unsigned short int choice); Define the following constants #define WORLD 1 #define MOON 2 Call the Hello. World( ) function from main( ), Correct errors until the stud programs compile, link and run. Design and test the Hello. World( ) function so that the call Hello. World(WORLD) builds a copy of the string "Hello World", outputs the string to the screen, and returns a pointer to the string. Hello. World(MOON) builds a copy of the string "Hello Moon", outputs the string to the screen, and returns a pointer to the string. NOTE: -- You can build the code in any fashion you wish (except by plagiarism) as long as it has valid functionality. 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 8

Lab. 1 Part 1 – TDD approach The customer provides tests in the form of a. doj file to check that the function char *Hello. World(const unsigned short int choice); performs as expected. The requirements are #define WORLD 1 #define MOON 2 Hello. World(WORLD) builds a copy of the string "Hello World", outputs the string to the screen, and returns a pointer to the string. Hello. World(MOON) builds a copy of the string "Hello Moon", outputs the string to the screen, and returns a pointer to the string. NOTE: -- You can build the code in any fashion you wish (except by plagiarism) as long as it has valid functionality. NOTE: -- Details of the tests are also provided to you in “open source” format so that you can develop variants for your self 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 9

Provided Tests TEST(hello. WORLD, DEVELOPER) { char *pt = NULL; pt = Hello. World(WORLD); EXPECTED_FALSE(pt == NULL); CHECK(strcmp(pt, "Hello World") == 0); } Add notes TEST(hello. MOON, DEVELOPER) { char *pt = NULL; pt = Hello. World(MOON); EXPECTED_FALSE(pt == NULL); CHECK(strcmp(pt, "Hello Moon") == 0); } 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 10

Where to start? n Step 1 n Develop a Visual. DSP++ project for the Blackfin n Step 2 n Add to the project the “simplest possible code” that includes the tests and will compile, link and run – and not crash the system n Note we know that this code will fail all the tests except the test that it will “compile, link and run – and not crash the system 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 11

Required minimum header #include “VDSP_TDD_Tests. BF 533. h” #define SCREEN_OUTPUT 0 x 1 #define SHOW_SUCCESSES 0 x 100 #define SHOW_FAILURES 0 x 200 #define ALL_TESTS 0 x 1 void run_tests(int output_code, int tests_code); TEST(hello. WORLD, DEVELOPER) { char *pt = NULL; pt = Hello. World(WORLD); EXPECTED_FALSE(pt == NULL); CHECK(strcmp(pt, "Hello World") == 0); } OTHER TESTS 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 12

Additional Code needed #define WORLD 1 #define MOON 2 int main(void); char *Hello. World(const unsigned short int choice); int main(void) { run_tests(SCREEN_OUTPUT | SHOW_FAILURES | SHOW_SUCCESSES , ALL_TESTS); } char *Hello. World(const unsigned short int choice) { char *pt ; WHAT CODE IS NEEDED HERE AS A MINIMUM? } 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 13

Where next? n Step 1 Develop a Visual. DSP++ project for the Blackfin n Step 2 n Add to the project the “simplest possible code” that includes the tests and will compile, link and run – and not crash the system n Note we know that this code will fail all the tests except the test that it will “compile, link and run – and not crash the system n Step 3 n Modify your stubs so final program satisfies the tests you have developed n Refine (refactor) the code so “quality” is present n Step 4 n Add all the customer tests provided (see write-up) n Modify the code so that it satisfies both your test and the customer tests n Refine (refactor) the code so “quality” is present n 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 14

The TEST MACRO Add notes here MACRO implies? #include “VDSP_TDD_Tests. BF 533. h” TEST(TEST_NAME, GROUP_NAME) { } TEST(hello. WORLD, DEVELOPER) { char *pt = NULL; pt = Hello. World(WORLD); EXPECTED_FALSE(pt == NULL); CHECK(strcmp(pt, "Hello World") == 0); } 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 15

Available ASSERTS n Long int tests – 32 bit – typical for “C++” n n n CHECK(condition) – Success if passes CHECK_EQUAL(expected, actual) EXPECTED_FALSE(condition) – Success if fails ARRAYS_EQUAL(expected, actual, length) CHECK_VALUES(expected. Temp, condition, actual. Temp) DOUBLES_EQUAL(expected, actual, threshold) 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 16

Embedded ASSERTS n Short int tests – 16 bit – typical for embedded systems n n SHORTS_EQUAL(expected, actual) SHORTS_CHECK(expected, condition, actual) USHORTS_EQUAL(expected, actual) USHORTS_CHECK(expected, condition, actual) n Timing of routine – Blackfin Specific n MAXTIME_ASSERT(BF 533, max_time, function) n Useful utility n MEASURE_EXECUTION_TIME(BF 533, timetaken, function) n Examples available in the tests associated with Lab. 1 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 17

ASSERT FORMAT #define CHECK_VALUES(expected. Temp, condition, actual. Temp) if (!((expected. Temp) condition (actual. Temp))) { FAILURE 1(#expected. Temp##" !"#condition##" "#actual. Temp); } else { SUCCESS 1(#expected. Temp##”""#condition##" "#actual. Temp); } 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 18

Practice – Test design n Design a test that will – details in class 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 19

Practice – Assert Design n Design an assert that will determine whether the lower 8 bits of a variable is identical to the lower 8 bits of a second variable. n The two variables should remain unchanged by the assert (since they may be reused later) n The upper 24 bits of each variable MUST be ignored in the assert 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 20

Tackled today n Why test? n Difference between n TLD – Test Last Development n TDD – Test Driven Development (Test First Development) n Examples used in Lab. 1 marking n The required program for Lab. 1 involves minor modification of the functions developed in the first assignment. n More details on the testing process n Design of custom TESTs and ASSERTS 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 21

n Information taken from Analog Devices On-line Manuals with permission http: //www. analog. com/processors/resources/technical. Library/manuals/ n Information furnished by Analog Devices is believed to be accurate and reliable. However, Analog Devices assumes no responsibility for its use or for any infringement of any patent other rights of any third party which may result from its use. No license is granted by implication or otherwise under any patent or patent right of Analog Devices. Copyright Analog Devices, Inc. All rights reserved. 12/21/2021 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 22