Course code: BARR-11
Years with company:
Primary programming language:
Other programming languages:
assembler, .NET (Visual Studio Basic), scripting (windows)
Unit test harnesses:
Never used one
We are mainly interested in the Embedded aspects of TDD. How do we test stuff that is cross-compiled? Do we need to create a hardware "simulator" for the tested application?
Test practice now:
Programmer(s) are paired with QA tech(s). They participate together in creating the software specifications (algorithms, flow charts, etc.) Then, the programmer tests his own code, before handing it over to the QA tester. The QA tester often has a debugger, and will perform debugging tasks using it (i.e. insert breakpoints and look at internal variables/states).
Other possible tests:
- black-box testing
- monkey tests
- reusing code (however, this doesn't guarantee successful integration of this pre-tested code...)
We are keenly aware that as applications get bigger, testing costs a lot, especially the regression tests, which should be automated somehow.
Embedded ARM MCUs, 16-bit MCUs, non-ARM 32-bit MCUs
Mostly IAR's suite of C cross-compilers/linkers/debuggers
Informal standards, loosely based on Barr's (nothing even close to MISRA...)
Function too long:
We don't... however, informal standards try to limit functions to single jobs.
Rarely done, unless we have a problem, and a programmer needs help
Favorite thing about dev:
Getting to see stuff work!
Least favorite thing about dev:
Continuously retesting for regressions (i.e. prior bugs that come back out.)
Using a framework to test code (i.e. write the test first, then write your code to pass the test.) Re-use the test continuously to ensure there are no regressions.
Why are you attending:
How does TDD apply to the Embedded with H/W I/O's, as opposed to iOS or Windows? How do I test GUI elements? How do we apply continuous integration (Agile!) methodologies? How can test suites/frameworks work with C (and legacy C) code?