Course code: BIRD-1

Years with company: 4.5

Years programming: 20

Primary programming language: C++

Other programming languages: python, C, java, javascript, typescript

Unit test harnesses: GTest, JUnit, pyUnit, nUnit

Something else: I like to play music (piano and guitar) in my spare time.

Test practice now: Haphazardly. I start with unit testing, but once the work of mocking becomes large, time pressure generally puts the focus on writing more features rather than mocks. At the intermediate level, we do some integration testing. For example, test that all endpoints of our embedded webserver respond as expected, with the hardware mocked out. At the final level, we test that the UI behaves as expected and that the device behaves as expected, but often overlook testing error conditions or trying to cause error conditions.

Target system: Currently it is an Arria 10 SoC, which is serving up a webpage for user control.

Dev tools: VS Code, Visual Studio, PyCharm

Build time: 31-60 seconds

Coding standard: We do not have a coding standard which is enforced.

Function too long: When it tries to do more than one thing.

Code reviews: Generally, the the reviewers know what the code is supposed to accomplish and the primary developer explains how the code achieves the goal.

Code time: 50

Test time: 25

Debug time: 25

Favorite thing about dev: I building a system to accomplish a task and partitioning the complexity into realizable components.

Least favorite thing about dev: Moving targets.

Tdd knowledge: I know that the idea is to define the tests before writing the code. However, I've found that very difficult to do in practice.

Why are you attending: I have two major questions that I would like practical answers to: 1. In the embedded world what are good approaches to mocking out hardware. 2. How do you minimize the impact of changing requirements while using TDD.