| Integration and Functional/System Tests. |
stm32F429 with motors, pumps, and various peripherals. |
Keil MDK
Segger JLink
VS Code |
We are developing software development workflows which are now including Code Reviews with associated Git Pull Requests. |
1-5 minutes |
4 |
2 |
4 |
Show
|
| Personal projects: largely TDD
Professional projects: a bit of TDD |
Current: Multi Arduinos used on a NASA project for photovoltaic R&D, to improve power output for the Lunar Gateway project. Simulated sun system for testing PV's on earth, plus balloons to 120,000 ft to calibrate things in space. |
Eclipse, Arduino IDE, |
Rare. Usually when there are questions. Or at end of completion of a new feature area. |
11-30 seconds |
30 |
30 |
40 |
Show
|
| unit test, integration test |
Embedded |
Visual Code |
Thorough code reviews |
1-5 minutes |
50 |
35 |
15 |
Show
|
| Our testing is done manually. Manually writing test cases for functions and modules. |
Arm Cortex-M4, mainly STM32F4s |
Keil uVision MDK, Parasoft C/C++ Test |
Reviews are done during pull requests of our git-based repository. |
30-60 minutes |
30 |
40 |
30 |
Show
|
| C production code is tested using CUnit. We chose this library because it was very easy to compile with our custom toolchain and does not require an OS.
C++ production code is tested with CxxTest. We chose this library because the python script that auto generates the test harness is easy to configure for use without an OS.
All unit tests are run on the target system. This allows us to unit test things like GPIO assertions and interrupt handlers. |
SoC with a custom MIPS processor. |
Custom C and C++ compiler and toolchain (gcc patch).
CMake for defining the build rules, which generate Makefiles we use for building.
CUnit for C unit testing.
CxxTest for C++ unit testing.
Emacs |
Usually involve 4-6 reviewers, each reviewer spends 2 weeks annotating the code. We use a custom tool that allows reviewers to collaborate and make in-line annotations without modifying the code. |
1-5 minutes |
50% |
40% |
10% |
Show
|
| unity test harness running on simulator,
manual with debugger |
Microchip dsPIC33, ST stm32f4, multiprocessor safety-critical system |
MPLAB X, Keil uVision, Visual Studio Code, batch files |
Not optimal |
11-30 seconds |
33 |
33 |
33 |
Show
|
| Testing the end product directly, with a human. |
Various avionics systems, some of which are ARM microcontrollers, and some which are x86 embedded linux systems. |
VSCode, Various IDEs for different microcontrollers, svn, git |
Using crucible currently, but not very experienced with it |
5-30 minutes |
50 |
20 |
30 |
Show
|
| I generate a test plan independent of the SW project based on user requirements/use-cases and then manually create a test document to run the SW through the tests |
x86/ARM |
Visual Studio, Eclipse, Android Studio |
In my prior position as a Sales Engineer I lacked access to really experienced mentors for code reviews. I'm hoping to get a lot of feedback from code reviews in my new role in Engineering. |
1-5 minutes |
60% |
30% |
10% |
Show
|
| Test using the product and multiple different inputs to see if I get the desired result. |
Zebra mobile printers running on c/c++ |
QNX Momentics |
I call another developer that is an SME in that area and show them my changes. They ask me to change something or give their approval then and there. |
1-5 minutes |
20 |
40 |
40 |
Show
|
| The most important are functional developer tests. Automated testing is carried out in development with cmocka.
Our system test writes much more extensive automated tests, mostly in Python. |
Our target systems are 2G / 3G / 4G radio modules. |
Qualcomm Build Environment, Qualcomm tools like QPST, QXDM and many more. |
Are done together with colleagues. |
5-30 minutes |
25% |
25% |
25% |
Show
|
| In most cases: pepper with Debugs, run & check, remove debugs |
Embedded multicore systems |
editor, compiler, debugger |
In most cases I am involved in advance and know the changes. |
5-30 minutes |
50 |
25 |
25 |
Show
|
| 1) compiler as static code analyzer
2) cpp check as static code analyzer
3) source code review
4) manual tests
5) cmocka on a daily base via jenkins
6) system test cases on a daily base via jenkins |
Embedded system with multiple cores, typically based on ARM 32/64 bit. |
Source Insight
Beyond Compare
CPP Check |
Very useful.
The skill is to invite people which are able to give useful feedback. |
5-30 minutes |
20 |
60 |
20 |
Show
|
| Jenkins CI
Debugger
Logging |
Embedded ARM |
Some |
Gitlab |
5-30 minutes |
? |
? |
? |
Show
|
| Testsuites provided by OS manufacturer (Windows kernel drivers), self written test suites (Android and Linux drivers), manually (everything). |
X86 systems with Windows or Linux, Android systems. No embedded systems! |
Many, depends on the kind and target of my current task. |
? |
1-5 minutes |
50 |
25 |
25 |
Show
|
| cmocka (job), by using it (private) |
in general: embedded platforms
in detail: embedded C or Linux based |
linux and google |
I try to take them serious. if I can't read it like a book or simply do not understand something, I complain. |
Under 10 seconds |
3 |
3 |
1 |
Show
|
| directly in client - server scenarios |
- |
- |
- |
5-30 minutes |
50% |
30% |
20% |
Show
|
| I typically add unit and integration tests when I am working on something that could have runtime errors that could result from my code, like parsers, algorithms, etc. In Rust I often avoid writing tests by using the type system to make certain error cases impossible. |
I typically develop on Ubuntu, but I recently got a Mac with Apple Silicon, and I also use Windows. Basically, everything. |
I typically use VS Code + Rust Analyzer + Cargo. |
We often develop in a mob, allowing for live code review. |
11-30 seconds |
80 |
15 |
5 |
Show
|
| Using some flavor of test driven development. |
No specific system in mind, usually application-specific. |
Primarily VS Code and everything that comes with it. |
Currently depends on the project, but generally pretty high-level. |
1-5 minutes |
60 |
20 |
20 |
Show
|
| gtest unit tests |
Cortex M4 dual controller system with BLE |
my collegues can answer this better than i could. |
my collegues can answer this better than i could. |
31-60 seconds |
20 |
20 |
20 |
Show
|
| gtest unit tests |
Cortex M4 dual controller system with BLE |
my collegues can answer this better than i could. |
my collegues can answer this better than i could. |
31-60 seconds |
20 |
20 |
20 |
Show
|
| For newly created software units, unit tests are applied during development ( first the logic is implemented, then tested).
For legacy code, tests are done by looking at the integration level. |
Low power Microcontroller 32-bits. |
Eclipse, IAR , Visual studio, azdo, EA. It depends on the project. |
Done via Pull request |
1-5 minutes |
20 |
50 |
30 |
Show
|
| unit-tests, integration-tests |
medical embedded devices |
VS-Code, Docker, gcc (cross compiler), gdb debugger, git, microsoft azure for change management and continuous integration |
one reviewer, using pull-request workflow |
11-30 seconds |
50 |
30 |
20 |
Show
|
| Currently, either Cucumber or just running the code against CI when I push to Git. |
Small evaluation board from ST fitted with a custom display |
Visual Studio Code
STM32CubeIDE |
We do mob programming, so we don't *usually* do code reviews as everyone is generally in the loop.
Sometimes when we have to do solo work, though, we'll pull 1-2 people in to ensure the code is sane. |
31-60 seconds |
15 |
15 |
70 |
Show
|
| ideally most of my day -- above 80% -- spent in the happy place of the red-green-refactor micro loop. 3 months into job here, about 5% in that place, 95% in what Geepaw calls GAK activity, others, yak shaving. |
bare metal rust some kind of STM processor (new to this space I am) |
rust; c++ for the legacy bits; applying strangler pattern to eliminate that, in hopes of 100% rust 0% C++ |
we mob - reiews are real time; asynchronous review (I'm looking at you, Git PR) are for those sad souls who default to solo. |
Under 10 seconds |
10 |
45 |
45 |
Show
|
| unit tests, integration tests, regression tests |
ARM Cortex M |
VSCode/Vim, GDB, STLink, Rust/C++ |
done by Mob/Pair Programming |
1-5 minutes |
3 |
4 |
3 |
Show
|
| Using google-test. Write code, then test.
Target is 100% coverage, for application logic down to device drivers. |
Embedded ARM device |
CLion
VS-Code
docker
clang, iar,
git
gitlab
|
we do a code-review per pull-request. review is done by second person, a pull-request holds code from 3-5 days of work. |
31-60 seconds |
40 |
30 |
30 |
Show
|
| As a DevOps engineer I mostly write scripts, and then by executing the script, I would see, wether the script works as expected or not.
(In my side projects I use gtest and the Visual Studio native unit test framework, and the debugger) |
n/a |
GitHub, Docker, Azure |
Done through pair coding and at the pull requests |
1-2 hours |
50 |
30 |
20 |
Show
|
| Combination of class-level unit tests, automated integration tests and system tests, plus manual exploratory manual testing. |
Arduino, embedded linux, embedded Windows, desktop exercises. |
Mix: Macbook, Eclipse, AtmelStudio, Aduino IDE, TextMate, Visual Studio |
varies by project, from zero to by weekly to pairing |
31-60 seconds |
10 |
40 |
50 |
Show
|
| |
|
VS code |
|
4-8 hours |
8 |
5 |
7 |
Show
|
| Writing unit tests for existing code |
Uses java script and python |
VS Code |
They go through peer review processes |
5-30 minutes |
33 |
33 |
33 |
Show
|
| Test in development environment, code review, test on target platform, then whole system integration testing. |
Laptop running Windows 10 |
Visual Studio, git, VMWare |
Peers review code individually and provide feedback prior to an online meeting where we review the code, what its supposed to do, and what it actually does |
Under 10 seconds |
60 |
20 |
20 |
Show
|
| We are using Google Test / Google Moack for Unit testing and we have own frameworks for end to end testing.
TDD is encouraged but not implemented correctly in the company. |
STM32 |
The team can provide information |
We use the four eyes principles and all code is checked before being committed. We have recently moved to using Git Pull requests for all activities (last week ) |
5-30 minutes |
40 |
30 |
20 |
Show
|
| - Manually on the target according test reports |
New development of a laser system for eye surgery - responsible for the FW in distributed system (Win10 (GUI); Linux (System controller); 7 x FW w/o OS). Subsystems with FW connected as slaves over USB to the System controller |
- STM32CubeIDE
- Enterprise Architect (UML/SysML) |
Only if searching a bug or if listed as a step in test report. No formal procedure defined. |
11-30 seconds |
70 |
10 |
20 |
Show
|
| As a DevOps engineer I mostly write scripts, and then by executing the script, I would see, wether the script works as expected or not.
(In my side projects I use gtest and the Visual Studio native unit test framework, and the debugger) |
n/a |
GitHub, Docker, Azure |
Done through pair coding and at the pull requests |
1-2 hours |
50 |
30 |
20 |
Show
|
| PyTest, UnitTest, other test API, and trial and error |
I am currently developing test software using a Windows 10 Lenovo x64 machine, but plan to create tests to be deployed and triggered on Raspberry Pi 4's for actual CDCI. |
Visual Studio Code IDE, Thonny IDE (for Pi Pico or lightweight Pi 4 work), GitHub Actions |
I do not have code reviews as a Verification Technician. |
1-5 minutes |
40 |
40 |
20 |
Show
|
| yes |
embedded platforms |
Tornado 2.2 |
peer |
31-60 seconds |
33 |
33 |
33 |
Show
|
| By unit tests using Google Test |
Insulin Pump System with two MCU's (stm32l476xx & stm32wbxx) |
- Visual Studio Code
- SEGGER J-Link
- Azure DevOps
|
The code reviews are done by a reviewer using the pull request feature of Azure DevOps. |
1-5 minutes |
30 |
50 |
20 |
Show
|
| On unit-test level we are using CppUTest. |
We are using a 3 cpu system |
Eclipse
VisualStudioCode |
Code reviews are done in Pull Requests of Azure Dev Ops by a technical leader. As a basis there are review report templates bound to our internal processes. |
11-30 seconds |
30 |
20 |
50 |
Show
|
| We are at the moment in the setup phase of our project.
We plan to use Google Test for Unit tests. And we want to have automated integration tests by using Robot Framework.
In my past projects testing was mainly done directly after implementation, but for my feeling mainly rudimental tests. There was a seperate System Test deparment. |
Embedded platform for ethernet fieldbuses. The plan is to use C++ where possible. |
Static Code Analysis
Azure DevOps
|
Currently in setup phase of the project and no fixed process is implemented so far. |
31-60 seconds |
40 |
20 |
40 |
Show
|
| Unit tests are executed during the build. Higher-level tests are still largely manual and/or ad-hoc. I'm seeking to improve this at the organizational level. |
Military vehicles, ranging from microcontrollers to desktop-level machines. |
Eclipse. |
We need better participation. Authors need to do a better job making it easier for others to participate.
We also fundamentally need to reduce the need for them by adopting better, more modern practices that include a lot more testing. |
11-30 seconds |
60 |
20 |
20 |
Show
|
| Depends on the project. In the project I am now: program the device, hope it works. The testing team will do the unit tests later. |
Medical device containing two microcontroller (one main, one supervisor) and bluetooth connectivity. It injects drug. |
VS Code / Eclipse, Parasoft, C, Azure Dev Ops, conan package manager |
Done in Pull Request in Azure Dev Ops. Sometimes thorough, sometimes not. |
5-30 minutes |
4 |
3 |
3 |
Show
|
| pytest or unittest |
embedded instruments, proprietary serial bus interface, gui is touchscreen, outputs are relay contacts, 4-20mA analog signals |
Rust software, C++ embedded, python system integration test automation |
team reviews |
5-30 minutes |
4 |
1 |
2 |
Show
|
| I test it manually and we have a test team |
Congatec QSeven imx6 running Linux |
VS 2019 for C# |
Code review is done mostly if there is a big change. |
5-30 minutes |
50 |
25 |
25 |
Show
|
| I test the code manually before I pass it on to the test engineers. |
A YOCTO linux systems that communicates with nodes that contain STM32 microcontrollers. |
Visual Studio
Qt Creator
STM32CUBE IDE
Texas Instruments CCS
Matlab |
We work with GitLab. When we want to commit larger changes, we normally create a merge request and ask a colleague to review the changes in GitLab. |
11-30 seconds |
40 |
30 |
30 |
Show
|
| Unit Tests, UI and integration tests are done manually |
Windows, Linux, Mobile Devives |
Visual Studio |
I dont have time for code reviews nowadays, they were done when I started programming |
Under 10 seconds |
70 |
10 |
20 |
Show
|
| fully from user standpoint |
Blackfin BF537 DSP |
VisualDSP++, Visual Studio 2019 |
rarely review |
1-5 minutes |
2 |
2 |
5 |
Show
|
| Currently NUnit and Ceedling (CUnit).
Write failing test, write code behind the test, make the test pass, commit, refactor a bit where necessary. (I could use more discipline on the refactoring bit). |
It's kind of a typical pre-web embedded system comprised of a microcontroller for data acquisition (embedded C) communicating to a single board computer running a Windows C# application via a CAN bus. |
For the embedded bit, use Atmel studio (now MPLAB X), but found that CLion is a more navigable IDE (refactoring tools inclusive).
For the C# side it's Visual Studio with the Resharper plugin (for unit testing and refactoring/autocomplete tools). |
We don't currently do any code reviews. At best in Valley Forge, it is one developer per product/product line. Would like to start - emphasis on readability/testability over style. |
31-60 seconds |
15 |
30 |
55 |
Show
|
| Manually functional with unit or simulation |
Windows PC and embedded windows PC |
Visual studio |
By my self |
31-60 seconds |
60 |
15 |
25 |
Show
|
| unittests, software in the loop for Signalprocessing |
Devices: Digiphone, ESG, Ferrolux
Software written in C on a Blackfin from Analog Devices
|
Visual DSP, Cppcheck, Jenkins, Matlab |
using ccpcheck to find defects |
1-5 minutes |
40 |
40 |
20 |
Show
|
| unittests, software in the loop for Signalprocessing |
Devices: Digiphone, ESG, Ferrolux
Software written in C on a Blackfin from Analog Devices
|
Visual DSP, Cppcheck, Jenkins, Matlab |
using ccpcheck to find defects |
1-5 minutes |
40 |
40 |
20 |
Show
|
| Manually check the functionality. |
Self-developed PCB board, controlled by an FPGA. |
Intel Quartus II, Visual Studio |
I'll give the code to a colleague to test.
|
31-60 seconds |
20 |
40 |
40 |
Show
|
| A combination of automated unit tests and manual testing on hardware. Historically, this has skewed mainly towards the latter, but in the last couple of years I have begun to test as much as possible via unit tests.
As a project team, we are looking to perform more automated testing on hardware. This is not something I have been involved with personally yet, but am looking forward to learning about it. |
We typically develop hand held products used for electrical test. These products often involve multiple processors, and need to be designed with safety in mind. |
Hstorically, IAR tools, but we're moving to GCC and other open source tools that play better integration with CI tools.
We develop primarily on Windows, although there is some Linux/WSL work (particularly with CI).
We also use Matlab/Simulink. |
We try to review all code that is integrated with the develop branch. There is no formal process for how. Sometimes it is done via screen share, sometimes via Bitbucket pull request. Reviewees nominate a reviewer familiar with the subject. |
Under 10 seconds |
70 |
20 |
10 |
Show
|
| None |
STM32 and Atmel range of microcontrollers |
Atmel studio, System Workbench (STM32) |
None |
11-30 seconds |
10 |
20 |
20 |
Show
|
| I currently mostly test simulink models (from which c++ code is being generated) via matlab scripts: framework inheriting from matlab.unittest. |
The system is a electrical measuring instrument which has two microcontrollers: STM32F7(GUI) and STM32L4R5 (measurement) |
matlab/simulink, visual code, gcc (wsl on windows 10), stmcube ide |
Our code review are either informal (just one reviewer without any records of any requested changes when the original work is relatively small) or done using pull request on bitbucket when the work is more substential. |
1-5 minutes |
33 |
33 |
33 |
Show
|
| Have started testing with google-test on new code. Code that is being reused is currently hard to start testing.. |
Embedded arm microcontrollers, controlling all kinds of hardware, sensors, motors ++ |
VSCode
STM32CubeMX
CMake, Ninja, arm-gcc, openocd
|
Policy to use 1+ reviewers depending on what has changed. Code needs to be approved (most cases) before it can be merged. |
11-30 seconds |
50 |
30 |
20 |
Show
|
| Unittest with the Google test framework |
STM32 microcontroller |
VSCode, MinGW, CMake, Ninja |
Performed by code owner after merge request is sent. |
31-60 seconds |
25 |
25 |
50 |
Show
|
| SonarCube + black/grey box module testing and functional test |
STM32 MCU |
Visual Studio Code / GCC |
Passed SonarCube screen, code is reviewed in meet with designated colleague with functionality and readability in scope. |
31-60 seconds |
33 |
33 |
33 |
Show
|
| Manually |
Embedded System |
VS code |
Peer review then senior programmer review |
11-30 seconds |
20 |
30 |
50 |
Show
|
| Manual testing. I try to make my outputs very clear, so I am able to follow the execution. I use debugging tools to step through the code. |
|
Visual Studio Code, Pycharm, Git |
I need to clean my functions. I need to optimize my code as I work with it, do not leave it to the end. |
5-30 minutes |
40 |
20 |
40 |
Show
|
| Debugger, test by using devices |
Atmel 8 bit mcu, PC, stm32 |
VS Code |
We use GitLab MR |
1-5 minutes |
20 |
20 |
20 |
Show
|
| I only did a little embedded here so far, there was no unit-testing, no regression tests, no gated checkin, no stubbing, mocking.. TDD.. forgive me for I know how I have sinned. |
Oof. I only did a bit of embedded. ATmega128, we don't really care about 'performance' that much, so careful thought into tailored code is often not an issue. Energy efficiency is not an issue, stack-size might be. |
I wish I could use e.g. valgrind.. GCC debug.. I like IDE's like CLion, but we often resort to Atmel studio and are bound to Windows ¯\_(ツ)_/¯ Visual Studio is still my favorite though. |
We check the style, but the code reviews usually happen 'after' a rather big chunk of work is done. We could be more agile, do not employ scrum. Code reviews are more of a feedback/suggestion oftentimes. |
30-60 minutes |
20 |
10 |
70 |
Show
|
| Mostly with manual testing |
AVR, ARM, x86, x64 |
Git, Visual Studio, clang-format, qt creator
(PuTTY, RealTerm, HxD) |
When I review others, I usually focus on execution speed/avoiding bloated code. I also enjoy code that looks tidy, and testable, if possible. |
11-30 seconds |
40 |
20 |
40 |
Show
|
| Building, uploading and running it, and then create a situation where changes in the code will show. Sometimes I need to provoke the system or even introduce another bug to see how the system reacts. Then, if the change seems to work, test the change in multiple different situations/over a period of time |
Robot firmware mainly |
Git, Jira, Microchip studio, VS Code |
We review git merges, or when someone is unsure about something |
1-5 minutes |
60 |
20 |
20 |
Show
|
| On bench setup or in real application. |
Autostore cube storage, automated logistics solution |
STM Cube IDE |
|
11-30 seconds |
50 |
10 |
40 |
Show
|
| Tested manually. |
Bare metal embedded plattform. |
Clang, Git, GitLab |
Multiple reviewers are approving the code changes before merging into the master branch. |
1-5 minutes |
40 |
20 |
40 |
Show
|
| With the goal of uncovering issues and bugs as early as possible.
Basically i'm doing manual unit testing. Manually manipulating input to modules/functions by any means in order to test all edge cases that I can think of.
In addition to this I would also do targeted/specialized integration testing before merging any code. |
Robot firmware running on STM32-controllers.
Requiring high degree of robustness and stability while also keeping focus on functional details.
Aspects related to performance and durability of the robots are important as well. |
Git.
Jira/Confluence.
SonarQube.
A bunch of internal tools. |
Partly good. |
5-30 minutes |
10% |
70% |
20% |
Show
|
| cargo test |
STM32Fx ( and some NXP ) |
gcc , VS code, git, rust |
All merges should be independantly reviewd and pass CI |
Under 10 seconds |
7 |
2 |
1 |
Show
|
| Some unit testing, a lot of manual testing |
STM32 microcontroller |
VS studio Code |
Merge request before a branch is merged to master. Reviewers will look through the code and accept/decline. Build server makes sure the branch builds, but does not run any tests. |
11-30 seconds |
20 |
50 |
30 |
Show
|
| Simulation via Simulink - Requirements tests, integration tests, baseline/equivalence tests. And on target hardware / system. |
Embedded control system. |
Compiler
Debugger
Code Editor
Version Control (Git)
Simulator (Simulink) |
Often slow. But thorough. |
Under 10 seconds |
Don't know |
Don't know |
Don't know |
Show
|
| Testing directly on the target hardware. No unit tests as such. |
Embedded system based on STM32 MCUs for controlling robots for storage system. |
Eclipse
Visual Studio Code
GCC
|
Code review are done upon merge requests by another software developer (lead) |
1-5 minutes |
60 |
20 |
20 |
Show
|
| System tests, automatic jig tests and local happy testing. |
B1 robot is a multi CPU system with real-time requirements and a fair bit of dynamics (motor control). |
gcc, VS Code, pytest (for integration testing), Confluence for doc, Jira, git, Gitlab. Clang-format checks on commits (new). SonarQube for analysis |
We have MR (Gitlab merge request) that needs to be approved before they are allowed into the master branch. We have some preliminary checklists of what to check and are currently requiring 1 approver and preferably also a second reviewer. |
5-30 minutes |
2 |
2 |
6 |
Show
|
| GTest |
Not sure, I'm a new engineer at this company. |
VSCode, mingw, gdb/make/ninja, arm toolchain. |
Not sure, I'm a new engineer at this company. |
1-5 minutes |
40% |
40% |
20% |
Show
|
| Gtest, GMock |
Bare metal Arm Cortex-Mx MCU's |
VS Code, Eclipse |
Before any merge request there is always min. 2 colleagues which go through the code for style and compatibility. |
11-30 seconds |
50 |
10 |
40 |
Show
|
| By running it on the target. With debugger, print statements or normal operation depending on how much has changed. |
Embedded systems, STM32 |
Git,
Gitlab,
Jira,
Eclipse,
Visual Studio Code |
One or more relevant persons will look through the changes and confirm it does what it is supposed to and adheres to the defined coding guidelines. The author is responsible for testing the code and making any requested changes. |
11-30 seconds |
unknown |
unknown |
unknown |
Show
|
| Bench testing (have a std set of instructions and debuggers) + we have dedicated team to do unit testing |
Linux |
Different IDEs |
We use code collaborator to do code reviews. Usually 2-3 reviewers+ moderator are present |
31-60 seconds |
4/10 |
4/10 |
6/10 |
Show
|
| Depends on the feature/issue I'm working on.
For feature, I use T32/lauterbach to add breakpoints and verify the states of the variables. For issues I re-run the failing tests and recommend adding additional tests to increase coverage. |
ARM R8 based embedded system. Bare metal programming. |
lauterbach, ARM toolchain |
n/a |
1-5 minutes |
4 |
3 |
3 |
Show
|
| Running on actual HW that has attached debugger
Pre-commit tools
Simulator
|
Enterprise SSD |
Visual Studio
GCC / GDB
ARM cross compiler / assembler
T32 debugging |
Peer review with review system |
5-30 minutes |
20 |
30 |
50 |
Show
|
| Run test cases |
SSD |
Lauterbach T32 emulator |
Our code need be reviewed by at least one member from each of 3 groups. |
31-60 seconds |
4 |
3 |
3 |
Show
|
| Modify code to force code paths. |
DO NOT PROVIDE ANY CONFIDENTIAL, SENSITIVE OR EMBARRASSING INFORMATION IN YOUR REPLIES. |
IDEs, VI |
DO NOT PROVIDE ANY CONFIDENTIAL, SENSITIVE OR EMBARRASSING INFORMATION IN YOUR REPLIES. |
5-30 minutes |
30 |
40 |
30 |
Show
|
| bench test, some regression test cycles |
ARM based SOC |
lauterbach t32
UART
Firmware traces |
code collaborator, standard review process with 2 peer and 1 moderator |
1-5 minutes |
2 |
2 |
6 |
Show
|
| Targeted testing / injection on real devices and in simulation environments, plus automated sanity test suites |
Proprietary SSD devices |
ARMCLANG, SlickEdit, Git, Visual Studio, make |
Some automated coding standard checking, but loosely enforced. Emphasis on correctness and functionality over style. Quality and scope varies depending on factors unrelated to the code (schedule, reviewers, etc.) |
1-5 minutes |
80 |
10 |
10 |
Show
|
| Regression testing |
various:
SystemC model
Python models/parsers
NVMe SSD device FW |
VS Code, GDB |
varies: For model development, optional Bitbucket centric reviews. For FW, code collaborator required. |
11-30 seconds |
40 |
20 |
40 |
Show
|
| bench tests, debugger manipulation, integration tests |
Many CPUs, lots of hardware acceleration. |
VSCode, Trace32, home made. |
use of review bots is handy. can take a long time to get a review completed. |
1-5 minutes |
40 |
40 |
20 |
Show
|
| Bench test and putting breakpoint in the code |
I used Linux and windows both as target systems |
Source Insight for C++ development |
I make sure to file a bug if I see an incorrect implementation |
1-5 minutes |
30 |
40 |
30 |
Show
|
| using host applications developed by third parties or internal test teams |
Linux, windows based systems connected to SSDs |
ARM DS5, VS studio, Source Insight |
I look at code structure first then logic |
4-8 hours |
30 |
30 |
40 |
Show
|
| different team does the testing. no unit testing |
Samsung ASIC |
ARM, Bash, batch |
reviews consist of syntax and logic verification. |
1-5 minutes |
60 |
10 |
30 |
Show
|
| Test applications using the APIs of my code. |
Mostly embedded devices based on a ARM solution, with Linux or ThreadX. |
The toolchain for our targets based on the supplier delivery (SCons, bitbake, gnu compiler chain for the build system.
Lint and CppCheck for static code analysis. |
We mostly use GitLab. On older projects based on ClearCase, we use a ms-word review-template. |
5-30 minutes |
40 |
40 |
20 |
Show
|
| build, and afterwards by flashing the module, |
Wireless module, with a lwm2m client, connects to a web server and helps with provisioning of an embedded SIM. |
source insight, vim/gvim. +Qualcomm tools to debug. |
normally done in gitlab |
5-30 minutes |
2 |
3 |
5 |
Show
|
| As unit test with bash scripts, with intention for automatisation in CI (jenkins). If not possible only manually. Especially for audio topics to recognize if audio path really enabled we have few sensor options to realize woking software. |
Embedded system with mostly ARM processor, main software delivered by processor producer, do we advancing the system and make it compatible in the customer environment. |
Source Insight, Notepad++, propiritary tool of the the processer producer (Qualcomm, Mediatek), git (last years), before clear case as version management |
Reviews in git lab: Check for syntax problems or obviously better to handle functions. To get deeper in the right |
5-30 minutes |
6 |
2 |
2 |
Show
|
| As I am mostly bugfix others code or just enhance vendor code, tests are usually very specific. Often this is done by individual agreements (case-per-case) with system test department. |
several SoC's form Qualcomm, MTK, ... |
plain text editor + vendor specific env. |
project specific. Currently: most changes are to be reviewd by at least one another developer using gitlab. |
1-5 minutes |
30 |
10 |
60 |
Show
|
| Jenkins CI server |
64 bit ARM/Cortex processor for 5G products |
GIT,Jenkins |
The code review is automatically initiated by pushing the code changes to the server. Sometimes it is challenging to understand the functionality when the review contains a lot of code. |
5-30 minutes |
7 |
2 |
1 |
Show
|
| Ci, Jenkins |
Several Base band Processor systems |
gcc, make, cmake |
Gitlab tools |
5-30 minutes |
60 |
20 |
20 |
Show
|
| Jenkins, CTS |
Android |
Compiler, Source Insght, Lauterbach debugger |
Organized with Jira tooling |
5-30 minutes |
20 |
60 |
20 |
Show
|
| manually |
Mobile Phone SOCs |
several |
GitLab based merge requests
documented in Jira |
30-60 minutes |
33 |
33 |
33 |
Show
|
| unit tests, on target tests |
various vendors using different OS, e.g. Siemens, TTPCom, Qualcom, MediaTek, Intel |
gcc,g++,vendor compilers, ...
make, cmake, scons, ...
gdb, Lauterbach, language debuggers
vim, emacs, SourceInsight, Eclipese, ...
gprof, gcov
ClearCase, git, mercurial
Jenkins, Gitlab, Jira, Confluence, ClearQuest
...
|
using Gitlab merge requests |
1-5 minutes |
50% |
30% |
20% |
Show
|
| I write every line of code imaginable, as fast as I can, and use a binary search to find the bugs |
sdf |
asdf |
asdf |
11-30 seconds |
45 |
45 |
10 |
Show
|
| unit or bench test by developer and then test cases by test group |
Linux Debian or VxWorks |
workbench |
performed with each release |
30-60 minutes |
0 |
0 |
0 |
Show
|
| internal group |
cellular tracker devices with various sensors for perishable and healthcare market |
na |
internal |
Under 10 seconds |
0 |
0 |
0 |
Show
|
| Testing by running on target - testing function and unhappy paths. |
Linux on arm, VxWorks on X86 |
Eclipse, Workbench/Tornado |
We do them, from an internal check list enumerating items to check. |
1-5 minutes |
35 |
50 |
15 |
Show
|
| I build my own testing classes/blocks/methods/functions to unit test my code vs expected results. |
Windows, PLCs/Controllers |
For my current job I use ISaGRAF, VS Code, Visual Studio and StarTeam for version management. |
Code reviews with peer developers. |
1-5 minutes |
25 |
45 |
30 |
Show
|