Course code: JHAP-1
Years with company:
Primary programming language:
Other programming languages:
C++, Python, Rust
Unit test harnesses:
Unity, GTest, Catch2, Doctest
I have two rescue dogs: a puggle and a lab mix.
Test practice now:
Using a combination of CMake and CTest (usually with Catch2) or using ceedling with Unity and FFF
ARM Cortex-M microcontroller
vim, IAR, cmake, gcc, clang, VS Code
Under 10 seconds
Our company (for C) uses an adapted Barr Group coding standard. For C++ I tend to use LLVM's style guides and try to follow the ISO CPP Core Guidelines elsewhere.
Function too long:
When it takes up more than one page in vim.
Different projects use different solutions. Embedded work tends to be using Collaborator, but other projects have used Crucible since it *can* integrate well with JIRA (though often not that well in practice).
Favorite thing about dev:
I like solving complex problems. For embedded specifically, I like that it has a real, physical impact outside of the computer.
Least favorite thing about dev:
All the paper cuts and difficulties that come with writing software that works well and consistently. It's exhausting having to go through 20 searches and try 8 different solutions before finding the vaguely documented solution for your problem.
I know that it is a methodology that revolves around writing the test code first, then writing the implementation to satisfy the tests. Strict TDD would require writing test code that fails first, then fix it as simply as possible.
Why are you attending:
I want to improve the software quality of our organization. I've tried using TDD on previous embedded projects but the time required to look up how to do things in C and adapt build systems meant I couldn't do much due to time constraints.