Training Preparation -- Current Practices of 100 Attendees
| How do you test your code? | What is your target system? | What development tools do you use? | What is your code review practice? | How much time does it take to do an incremental build, load, and start running your code so you can start to test it? | What percentage of your development time is spent coding? | What percentage of your development time is spent testing? | What percentage of your development time is spent debugging? | |
|---|---|---|---|---|---|---|---|---|
| Using Jest to perform unit testing | Embedded devices running Linux for streaming applications, commonly using C/C++ | Visual Studio Code, Bitbucket, Node.js, Jira, Azure IoT Hub | First I pull the code and try to compile it. If the compilation finished successfully, I review the implementation and look for border cases. | 1-5 minutes | 70% | 20% | 10% |
Show |
| using system and module level Testbenches | Communication systems, Wireless comms, Video and image processing, Cybersecurity | Vivado, Quartus, Keil, Visual studio, Workbench, ARM and TI tools as and when needed. | between 30 minutes to and hour. | 5-30 minutes | 50 | 20 | 30 |
Show |
| My dat-to-day role involves software integration, I depend on integration tests. But I would like to learn Unit testing and I think that is the right way to do. | Linux based System on Chip. Our development is in Userspace Middleware. | GCC Python Behave Gherkin tests | We use gerrit | 30-60 minutes | 15 | 10 | 75 |
Show |
| We are using google test for unit testing and a proprietary system for integration testing | Set-top-box | I'm personally using VSCode | We use gerrit | 5-30 minutes | 30 | 30 | 40 |
Show |
| unittesting using Cpputest/googletest and DMS testing which tests the whole code base. | Linux embedded system built on Set Top Boxes | Visual Studio | Code review using gerrit. | 1-5 minutes | 20 | 60 | 20 |
Show |
| Currently I use several test tracks | There are several different targets depending on the region and | Visual studio code, putty, build server. | Our code reviews are done via gerrit | 5-30 minutes | 30 | 30 | 40 |
Show |
| unit tests, integration tests and some times fullstack | Set top box | We use a whole lot of custom tools mostly lunix based. Git for version control, gerrit for review, jenkins for dev-ops | use gerrit | Under 10 seconds | 30 | 50 | 20 |
Show |
| Test at module/component/multi-component levels. | Embedded linux | Coverity static analysis Vim Neoclide/coc (clang completion) vim ccls | We use gerrit - code from a team member is viewed by all, but only 1 person is required for sign-off. A bot also performs checks on the change. | 1-5 minutes | 10 | 55 | 35 |
Show |
| N/a | N/a | N/a | N/a | 1-5 minutes | N/a | N/a | N/a |
Show |
| I have just started to unit test. Very new. Previously manual. | Embedded processors | CppUTest, IAR | Mostly line by line, peer review. | 11-30 seconds | 30 | 30 | 40 |
Show |
| functional tests | Gas detectors using STM-ARM cores and SiLabs 8051s | Eclipse based or IAR | Every member of the team reviews code and makes comments on compliance with the standard and business logic. | 31-60 seconds | 30 | 30 | 40 |
Show |
| ATDD, TDD, Exploring manual test. | web app, ios-app | jet brain IDEs. | face2face every 1 hour | Under 10 seconds | 50 | 40 | 10 |
Show |
| Debug later | Embedded C running either bare metal or FreeRTOS on an MSP430 | IAR and CCS | Peer review | 11-30 seconds | 30 | 30 | 40 |
Show |
| Starting to use cpputest, but sometimes difficult. Our main way of testing is flashing to the target unit and running automated tests with real stimulus. It takes tens of minutes to hours to complete a test. | ST Micro, low power, arm | IAR | None | 1-5 minutes | 3 | 2 | 5 |
Show |
| Jenkins Continuous Integration, bench top and functionality testing | STM32L4+ microcontroller with various communications interfaces and SAM4L microcontroller RF system | IAR Embedded Workbench | Informal | 1-5 minutes | 50 | 25 | 25 |
Show |
| On the fly, how it seems appropriate at the time. (hoping to improve this :) ) | Low power custom embedded board (variety of ARM Cortex-M micro controllers) | IAR EW, Ozone | Fairly informal, conference room, go function by function. | 11-30 seconds | 30 | 30 | 40 |
Show |
| We build test in python and run the in Jenkins. Hard to cover all corner cases when building the test. Our CI systems is something like this: get code from repo, compile code, lint code, flash hardware with new code, run test then email results to developers. | I would rather not say. | IAR,QP, Git, and Vault | When software gets to a point we feel at a good state, we schedule a code review and invite our peers. We try to give people plenty of time review. We highlight pieces of code that we might have questions about ourselves so that others can help. | 1-5 minutes | 25 | 50 | 25 |
Show |
| Collection of unit test cases, tested on development boards. | ARM Cortex M3/4 microcontrollers, low-power environments, baremetal software | GCC, Cygwin, Eclipse, IAR | Code reviews aren't often used, getting started using Gitlab's review feature. | 31-60 seconds | 30% | 30% | 40% |
Show |
| end-to-end testing using CI | embedded C for micro-controllers only, cannot use C++ due to project restrictions (not even for unit testing) | IDE | GitLab Merge Requests or Fagan depending on project type | 31-60 seconds | 60 | 10 | 30 |
Show |
| using continuous integration | mcu | gcc, make, iar, | what are those? | 5-30 minutes | 60 | 20 | 20 |
Show |
| I write some short functional tests and try to capture the different use cases. | n/a | IAR, Eclipse. | n/a | 31-60 seconds | 50 | 25 | 25 |
Show |
| in production | i have different targets | vi | does it compile? | 1-5 minutes | 1 | 1 | 98 |
Show |
| breakpoint debugging instrumentation test gpio Watch windows Memory windows | Cypress PSoC 5LP, PSoC 6, Microchip PIC18s, dsPics, SAME family, other processors over the years. | IDEs, Programmer/Debuggers, Logic Analyzers | seldom, working to incorporate into new designs | 1-5 minutes | 20 | 30 | 50 |
Show |
| Before ceedling I'd often test code using print statements or toggle pins if testing on hardware. For timing critical testing I might throw test data into an array and print it all at the end. But that took a bit of extra work and system overhead. | I really like Notepad++ | My team only just formed and hammered out our code standard. We haven't had any code reviews yet, but plan to. | 11-30 seconds | 40% | 40% | 20% |
Show |
|
| Testing scripts which attach to the target via debug UART. These use python and Q_SPY | Cortex M0/M3/M4 and Xilinx Zynq | IAR/GCC SEGGER JTrace/Ozone for tracing | Depending on the speed of the project, code reviews and architecture meetings are held with varying frequency. | 11-30 seconds | 20 | 30 | 50 |
Show |
| Unit test, system-level test | ARM Cortex M4/A5/A9, TI MSP430, TI DSP | IAR, gcc | Sparse | 1-5 minutes | ? | ? | ? |
Show |
| Most important is to design code as separate testable modules. I can then write a test program that pumps data through the modules and checks the outputs. | ARM processor, battery powered, lots of sensors, radio communications. | IAR (maybe Green Hills also) | Project dependent. Some have none. Others have full up reviews in TeamForge + Gerrit. | 1-5 minutes | 70w/design | 20 | 10 |
Show |
| Manual unit tests; full unit testing over time, sometimes with the aid of continuous integration with the embedded systems in the loop | Various custom boards with mostly various ARM Cortex-M3/M4-based microcontrollers; FreeRTOS, bare metal, or QP, depending on project; mostly C, but sometimes C++ | IAR or GCC | Usually small sections get reviewed line-by-line | 11-30 seconds | 10% | 60% | 30% |
Show |
| unit tests, functional tests, performance tests | c++, python | xcode, visual studio, pycharm etc. | Each code change is reviewed by reviewers of that code area. | 31-60 seconds | 70 | 15 | 15 |
Show |
| I write tons of runtime asserts, step through the code, then manual verification. This is followed up with black box testing. | It's a cross platform (Windows, Mac, iOS, and Android) video editor. I work on the Win and Mac UI and a library that's shared across all platforms. | Visual Studio, Xcode | We use browser-based tool called Code Collaborator. It's not a good tool, and is downright hostile for reviews that end up having multiple revisions to any file. | 1-5 minutes | 40 | 30 | 30 |
Show |
| manual app testing, Unit Testing | Rush Android application | Android Studio, Perforce, gradle | our reviews are fairly good | 5-30 minutes | 30 | 10 | 60 |
Show |
| blackbox | Win/Mac | VisualStudio, XCode | it's required | 1-5 minutes | 60 | 10 | 30 |
Show |
| Most testing is done by walkthroughs of the actual app (no formal testing infrastructure). Since my work has a strong focus on custom UI implementation, and less focus on data models or computational engines, unit tests have less immediate relevance, and I haven't yet seen a UI testing framework that was worth the hassle. | iOS 12 and 13, both compact and regular layout. I work on a cross platform app team (Mac/Win/Android/iOS); my work is almost exclusively in iOS, though I do deal with much code that is shared between the platforms. | Xcode, Perforce (soon to be git), macOS command line. Python scripts which generate the Xcode projects. Collaborator by SmartBear for code reviews. | All submission are reviewed by at least one other person, using Collaborator (by SmartBear). Check in comments must include the review URL. | 1-5 minutes | 30 | 10 | 60 |
Show |
| mainly use target PCBA build and use with debug interface | based on product features target is product PCBA with debug interface SWD | IRA and SEGGER STUDIO | Bitbucket code review with Pull request | 11-30 seconds | 30% | 40% | 30% |
Show |
| n/a | n/a | I used to use emacs, ant, Eclipse. I started learning IntelliJ. | n/a | 11-30 seconds | 0 | 0 | 0 |
Show |
| Functional testing. Write a bunch of code to do something, then test all the code as a whole. | Nordic nRF52 platforms ST platforms Atmel platforms Sensors, switches, relays 802.15.4 (BLE and 6Lo) | VS Code, IAR, Sublime | Peer reviews in Bitbucket | 31-60 seconds | 60 | 20 | 20 |
Show |
| Regression/Unit | Contiki based firmware running on Nordic NRF52 built using Gcc for Commercial Lighting Control applications | IAR Visual Studio Segger Embedded Studio Segger j-link | Peer Review though BitBucket Pull Requests requiring at least 2-3 sign-off depending on the code base | 1-2 hours | 33 | 33 | 34 |
Show |
| We manual test the code with gdb and evaluate the quality of the data. For logic we use small catch2 based tests that only run on development laptops so not on the target. A build pipeline checks if the code compiles | It's a nrf52 with no uart | clang-format, gcc, sonarcloud (for static code analysis), vim, jlink, gdb, cppcheck | At least one person should have a look at the code and mark it as ready for merge in github. | 31-60 seconds | 2 | 3 | 5 |
Show |
| Before reading your book I was writing code, building the code, pushing the code on the target and verifying in debug mode that the code I just wrote was working as intended. After reading your book I started to use ceedling to unit test my code. So now I'm coding and testing my code on the computer and when a bunch of module are ready to work together I to the same as previously but with less step by step debugging and more global verification like verifying the outputs with oscilloscope or logic analyser. | I'm currently using STM32F3 and F4 microcontroller families. | Eclipse + gcc for arm + openocd. | We don't have code review as we are a small team. | 11-30 seconds | 50 | 10 | 40 |
Show |
| Quantum leaps QUTest, custom framework for automating on target tests, VectorCast and remaining adhoc/manual tests on legacy code | My team develops FW for medical feeding pumps - the project I work on has 2 embedded Stm32L4 MCUs | IAR, Visual Studio, Surround SCM/Helix for version control and requirement management, Jira/Confluence for planning/tracking, Quantum Leaps QM for state-machine modeling | Required. We do them every "story" - present company has a longer turn around than I am used to. | 1-5 minutes | 80 | 10 | 10 |
Show |
| Code reviews, system testing, pre- deployment testing (code then test) | ARM-M, MSP430 | IAR | The are painful, long, and don’t catch the bugs that matter the most. | 31-60 seconds | 20 | 10 | 70 |
Show |
| A large part of our code is tested manually as part or a larger system. We're starting to adapt unit testing and a small portion of our code is unit tested. | Embedded systems. | Gcc, PC simulators, VS code. | Code reviews are done before every patch is submitted. A developer isn't allowed to review their own patches. | 1-5 minutes | 30 | 30 | 40 |
Show |
| We mainly use manual system level testing. We've recently started developing automated unit tests using the Google test suite. | Fitness devices. | vscode, jenkins | Each commit is reviewed by the team before it can be pushed to any remote branch. | 31-60 seconds | 4 | 2 | 4 |
Show |
| Using CTest and CI via github, bitbucket, travis, gitlab. Manual validation. | Typically ARM microcontrollers, Atmel AVR, PIC Microship, and others, usually bare metal, sometimes with RTOS. Some target systems are Linux or embedded Linux. Some target systems are Windows PC. | GCC, Make, IAR, Rowley Crossworks, Segger Embedded Studio, Atmel Studio, STM32 Cube IDE, MPLab X, and others. | Pull request or merge request online via bitbucket (or gitlab or github). Typically check for adhering to coding standard, and adhering to high-cohesion low-couple architecture for code placement. | 1-5 minutes | 50 | 25 | 25 |
Show |
| Manual testing mostly. | Most target systems are embedded STM32 based devices although it varies from project to project. Mostly Arm Cortex-M processors. | A wide range. IAR, KEIL, STM32CubeIDE as the primary toolchains. | It varies project to project based on the client I am working with. I often have a colleague review code that I write if possible. Many times I'm reviewing client and other developers code. | 31-60 seconds | 75 | 10 | 15 |
Show |
| I don't. | ARM & AVR uCs | sublime, GCC, AVRDude, | Weekly, peers outside the company, using zoom. | 1-5 minutes | 20 | 30 | 50 |
Show |
| combination of printf(...), and running on target and seeing if things break. | Some 32-bit micros, a QNX 4.25 based RTOS system, and hopefully soon, a more modern custom linux image. | Micro development in NXP Studio (Eclipse-based, uses gcc). QNX development with VS Code IDE, and on-board Watcom 10.6 C/C++ compiler/debugger. | Boss and I do high-level structure overview, and then go through more thoroughly as we deem necessary. | 1-5 minutes | 60 | 5 | 35 |
Show |
| Unit tests where possible, running off target. I've tried using drivers, and test doubles, but found it difficult in C. | I'm not normally doing embedded outside of hobby projects. Most of the embedded programming I've done is AVR ATMega based using the gcc-avr toolchain. I've tinkered a bit with STM32. | In this context, gcc CLion, CMake. | Ad hoc. | 31-60 seconds | 50 | 30 | 20 |
Show |
| When working from a spec, often there is an official test vector set that can be used for validation. Sometimes there is an alternative implementation for a different piece of hardware that can be used for reference. If neither is the case, | Various hardware security modules (HSM's) programmed in C or C++. We develop code in MSVS, but each target has its own proprietary C compiler, usually building in a Linux Docker image. Compiled binaries are then hand-loaded onto the target platform. | MSVS IntelliJ | In my opinion, code review is more about sharing knowledge than anything else. You can have great discussions about architecture and style, but it is uncommon for bugs to be found in the review process. | 1-5 minutes | 30 | 50 | 20 |
Show |
| Apllication code: Simple intergration test, but nothing automated. In the present team we are 3 embedded developers and 4 PC application developers. Two testers, one manager, a PO and a SW project manager Platform code: cppunit test of some parts of the code base | Embedded system for Food analysis NXP LPC4357 with multiple modules internal CAN communication 480*800 touch display SQLite database Data upload to a Foss Cloud solution | Green Hills Multi 7.1.6 compiler and debugger Visaul Studio 2017 as IDE and simulator Ues "Rant" for building | All code is reviewed, since last summer. The current project has run since late 2017 :-/ We use Azure Devops and I am quite happy with the this | 5-30 minutes | 30 | 40 | 30 |
Show |
| Manual | Mostly ARM | ATMEL Studio, Keil, MATLAB and Simulink | The design is reviewed with the software architect. I use sonarCube to verify the code | 31-60 seconds | 3/10 | 2/10 | 5/10 |
Show |
| Manually updating impute values for a function and compare the output values with the expected ones. | Confidential | Eclipse, Keil, IAR | Code review by senior developers | 1-5 minutes | 40 | 20 | 40 |
Show |
| I incrementally add functionality to the target code base, then submit customer programming to the code under development | Printers big and small | momentics and GNU compiler chain | They're fair but until one has been through a couple it's really hard to do much more than try to write code like everyone else wrote something similar | 1-5 minutes | 20 | 20 | 60 |
Show |
| The tests are partly unit tests and partly functional tests. Unit tests are run off-target. Functional tests on target. Test of algorithmic code and code integrating with the libraries offered by the vendor is tested on target. This approach has been chosen to ensure that differences in endianness, size of basic data types etc are sufficiently covered by tests. | The target systems are based on a number of different architectures. In general, debugging support is lacking - commonly reduced to output only when execution of the code returns 'nicely'. | Mainly Microsoft Visual Studio, gcc & IntelliJ | Code is reviewed by a colleague - sometimes by the colleague sole - othertimes as show-and-tell seances. | 5-30 minutes | 3/10 | 3/10 | 2/10 |
Show |
| * TDD unit testing for small well defined functionality. * Using a software implementation of the hardware abstraction layer. | Hardware Security Modules of various brands and different CPU architectures with down to 1MB RAM. The same code has to work on all platforms, therefore all code is written in C. | Visual Studio, IntelliJ IDEA | Code reviews should make sure: * The intended task has been done and that nothing is missing * Relevant tests are present * The code is: - Secure and follows guidelines - Easy to understand - In the right place - Better than it was before | 5-30 minutes | 70% | 20% | 10% |
Show |
| Automatic unit tests, integration tests and functional tests. Test code mostly in C and C++. | Embedded C code on HSM (Hardware Security Module). Focus on security, correct functionality and performance. | Visual Studio, IntelliJ IDEA, QT Creator | All code is reviewed by a peer programmer. | 5-30 minutes | 40 | 50 | 10 |
Show |
| I'm just starting to use CppUTest and TDD, moving away from the 'Debug later' approach. | It has a wide range of peripherals: an LCD, Ethernet, SD card, etc. | GCC, GDB, VIM, MPLAB X, Eclipse | I haven't had much experience with code reviews, I've primarily been a solo developer. | Under 10 seconds | 40 | 5 | 55 |
Show |
| We have a test actor that can work as the sending and receiving end of each code execution. This can be scaled from single events to full features. We leave #ifdef-ed in case we ever need to reverify code that we make changes to. | Embedded Atmel microprocessor | Keil IDE with the Keil ULink Pro | Our initial code drafts were brought in without much review because of time constraints, we're working on cleaning up now. Anytime we merged new code we used BeyondCompare to see exactly which code has changed. | Under 10 seconds | 65% | 15% | 20% |
Show |
| Progressive debug, usually confirming HW simultaneously as FW, and extending the FW to full feature | MCU based RTOS | Keil MDK UlinkPro | Delta comparison in BeyondCompare with verbal intention walkthrough on each item | 11-30 seconds | 30 | 40 | 30 |
Show |
| Functional testing | Consumer electronics | IAR, Vendor Specific IDEs | Informal | Under 10 seconds | 60 | 10 | 30 |
Show |
| Using CppUTest | Aircraft PFD in C++ running on a raspberry pi | VSCode, CMake, Git | I put out pull requests when I'm done working on a feature and wait for my coworkers to comment on it. Its the same thing when my other coworkers submit PRs too. | 1-5 minutes | 7 | 1 | 2 |
Show |
| Run it and see if it works. | linux based | eclipse | Have not done any code reviews yet | 11-30 seconds | 30 | 40 | 30 |
Show |
| I test my code using basic principles of TDD, but I would like to learn more | It's a vacuum cleaner robot that runs on an OS based on Linux Yocto | Eclipse IDE, Atlassian Stash | We do the code reviews using Atlassian Stash git platform | Under 10 seconds | 30 | 30 | 40 |
Show |
| Mostly functional testing w/ hardware. Occasionally I will write a short test program that will fully exercise inputs of a function, etc. | I design Lithium Ion Battery packs for power tools. I also design some tools for use on the packs occasionally. | IAR is my preferred compiler and debugger. Also, all the normal EE bench tools, Osc, DMM, etc. Lately been using Parasoft for static analysis. | Coding reviews are not "mandated" by our procedures. When we do have them, many times they get caught up in the minute details on a particular portion of code and become less effective. | 11-30 seconds | 45 | 35 | 20 |
Show |
| Umm.. use a lot of printf, and simulator | Most projects on Xilinx ZynqMP SoC, most of them are baremetal, then Linux and VxWorks. | gcc, clang, make, Simics, QEMU | peer review on an ad-hoc basis | 11-30 seconds | 20 | 40 | 40 |
Show |
| Purely system testing | PIC32 | MPLABX | Completed by a small software team | 11-30 seconds | 4 | 1 | 5 |
Show |
| unit testing, and run time testing with hardware | embedded 32bit ARM and 8 bit | IAR, eclipse, notepad++, visual studios | It is currently up to the engineer of a project to start a review. the are starting to become a requirement | 11-30 seconds | 40 | 30 | 30 |
Show |
| Barely | Smart meters | Eclipse, use, visualstudio | When there is time to | 1-5 minutes | 30 | 5 | 65 |
Show |
| We do functional tests with Ctest | I develop code for both a Renesas RX65 MCU and the ZON M3 and P3, embedded in a smart meter. I also code for PC. | CrossStudio for MAXQ30, IAR Embedded Workbench and Visual Studio Code | We don't have standarized code reviews | Under 10 seconds | 40 | 40 | 20 |
Show |
| Good question... In every company I have worked for, testion is a recurrent word that appears but, because of the tight delivery times the testing has been always avoided. Here, in ACLARA, our team leader is trying to change this. I had the chance to use CPPTEST but not in production. | Only about one? Right now the Renesas IC is a bit unknown. I now it is a 32 bits system, its endianess, some aspects of its configuration using its registers, peripherals... But all this, or most of all, is handled using a HAL layer. | Here in ACLARA we use IAR compiler for the target and MinGW for the tests using CMAKE to handle the tests and to build each of them. I like to code using vim (using cygwin now, because the use of Windows is mandatory) or VS CODE. | There are not code reviews right now. I have worked before using pair programming method and it worked well. | 5-30 minutes | 10 | 60 | 30 |
Show |
| I try to make new functionalities as isolated as possible so that we can then make unit testing on them. Thanks to Cmake we are able to launch our libraries and check if new changes in code have broken other modules. | We make Smart meters => embedded system | IAR embedded, Cmake, mingw | I try reviewing every little time what I am coding. Performing unit test helps. | 5-30 minutes | 30 | 20 | 50 |
Show |
| IAR | Under 10 seconds | 2 | 3 | 5 |
Show |
|||
| PC testing and testing in target device. | Renesas microcontroller and ZON P3S | IAR EW for Renesas and CrossStudio for MAXQ30 | DK/DA | 5-30 minutes | 30% | 50% | 20% |
Show |
| Creating tests on PC. I usually create single unit tests (when possible) and sometimes I create more complex test that involves more than one component and tests complex behaviours (entire module). This forces me to abstract hardware pieces and let me create single components(C modules) that works indendently each other. This also allow me to debug on a PC that is much easer than the embedded system. | Actually is a Renesas Chip (Rx651). Its a 32bits CPU at 120Mhz with 1.5MB of internal Flash, 640KB of RAM and 16MB of external Flash. | IAR embedded workbench (forced by company policy) VIM as my favorite editor | We seldom perform code reviews. | 5-30 minutes | 3 | 6 | 1 |
Show |
| PC and platform testing. | Smart energy meters. | Visual Studio Code IAR EW for Renesas | dk-da | 5-30 minutes | 20% | 40% | 40% |
Show |
| PC testing and in the hardware directly | Electric meters | IAR Embedded Workbench IDE Visual Studio Code | I do not know what is this | 5-30 minutes | 40% | 30% | 30% |
Show |
| Manually, debugging and checking that the firmware acts as it's supposed to do. | I develop libraries and code mainly for ZON P3S and a Renesas microcontroller, but also for PC | CrossStudio for MAXQ30, IAR, Visual Studio Code | I don't have any | Under 10 seconds | 30 | 20 | 50 |
Show |
| design , write and later test the small pieces of code written | Renesas RX651 MCU. Threadx RTOS | IAR embedded workbench | We do not have code reviews | 1-5 minutes | 30 | 50 | 20 |
Show |
| I haven't been long enough in this company to start testing my code. But as far as I know ADO pipelines are used to execute the unit tests. | Renesas RX | IAR, visual studio, eclipse | Not yer done in the actual company. But before I have used code collaborator to review the code of my colleges and my colleges reviewed my code with it. | 5-30 minutes | 5 | 0 | 5 |
Show |
| Functional testing. | 32 bit microcontroller. 640 KB RAM. 1.5 MB Flash. | IAR Embedded workbench | We don't do code reviews regularly. | 1-5 minutes | 50 | 25 | 25 |
Show |
| Depending on the project we employ TDD or just test different areas of code via CLI commands and debug from there. | ARM microcontrollers for the most part. | IAR Embedded Workbench, Eclipse, Simplicity Studio, git, Jira, gitlab | We have coding reviews typically. They vary from project to project, some are very detailed and the whole team reviews added features, others only require very little review. | 31-60 seconds | 30 | 40 | 30 |
Show |
| Basic unit tests for Python, static anaylsis tools for C. | Primarily ARM platforms with a host of peripherals, something like an EFM32 or EFR32, as well as some FPGAs with hardcores like the Zynq. | VIM+GCC (sorry) IAR | I've pushed for some more formal review processes on programs to leverage our on-site Gitlab. So, an issue tracker is created as a work order, a merge request is put in and tracked by an engineer. Two other engineers have to review and approve | 1-5 minutes | 30 | 20 | 50 |
Show |
| After code is written, I go back and write unit tests to verify functions and conditionals with expected outputs. | Most target systems are ARM-based embedded boards, ranging from snapdragon-like systems, to more GPU enabled, like TX2s. | Visual Studio Code, valgrind, gdb, vim, gitlab, mattermost | I usually code review other's code, and should spent more time doing this as well as have my own code reviewed. | 11-30 seconds | 70 | 15 | 15 |
Show |
| In the lab. | Embedded: ARMs or microcontrollers | Cross-compilers, IDEs, debuggers | Gitlab merge requests. | 31-60 seconds | 100 | 100 | 100 |
Show |
| Full system regression tests | ARM (zynq systems) | Current project - none | Full sw team review (3 people) through gitlab | 1-5 minutes | 25% | 45% | 30% |
Show |
| unit tests via gtester | Most of my work is targeted towards various linux ARM (Cortex A53) processors | gcc, gdb, vim, tmux, vscode | Code reviews usually consist of reviewing tests and test results. Ensuring that the developed feature is operating as intending. Also reviewing impact, i.e. memory/cpu usage. | 31-60 seconds | 70 | 10 | 20 |
Show |
| custom main files that run specific tests for unit testing | Embedded devices / micro controllers and microprocessors | PyCharm Visual Studio Community Edition Simplicity Studio | Usually non-existent, possibly one during merge request | 5-30 minutes | 30 | 25 | 45 |
Show |
| Unit test functions, or I'll use python or other scripting language to test parameters | I mostly work on micro-controllers | Simplicity studio, IAR | I haven't ad many. The few that I'v had have been one on one where I walk the other person through my code. | 11-30 seconds | 5 | 1 | 4 |
Show |
| I mostly test my code in small steps at a time. After developing a function, I typically test it immediately. This process continues until a new feature is fully developed, where I then integrate the feature into the system and perform integration testing. Unfortunately, system-level tests become repetitive following this approach due to the incremental nature of integration. I want to develop a better way to perform system-level tests that can check if previous work still functions as intended after integrating each individual new feature into the system. | - | Mostly IAR Embedded Workbench | Code reviews start whenever a feature is first prototyped and continue up until it is approved for merging with the codebase. | Under 10 seconds | 20 | 40 | 40 |
Show |
| I like to build an abstraction layer into my code that allows it to run on PC or embedded. Then I build a bunch of test cases that I run through it using a Python script. Output is generally plots of signal processing performance | Varies from embedded Linux to FreeRTOS mostly on ARM and x86 platforms. | Visual Studio Code, Cmake, Docker, and Atmel Studio. I prefer to develop using Linux. | Often there are no code reviews, I am the only person doing software. | 31-60 seconds | 20 | 20 | 20 |
Show |
| Feature specific unit testing during development. Hardware in the loop testing suite for system software as a whole. | Primarily ARM Cortex-Mx platforms. | IAR, GCC, Atmel Studio, & Simplicity Studio. | Reviews with relevant team members for feature branches before merging with development branch. | 11-30 seconds | 30% | 30% | 40% |
Show |
| 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 | 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). | Under 10 seconds | 20 | 20 | 60 |
Show |
| Ceedling for unit testing as much code as I can on development machine. Integration and system testing for rest of functionality. | Usually ARM Cortex-M4's. Sometimes Zynq platforms. | IAR EWARM Eclipse | Depends on project, but usually non-existent. When existent, use GitLab merge requests for comments/discussions/etc. | 11-30 seconds | 80 | 80 | 80 |
Show |
| SystemView, RTT Print logging, manual testing | Microcontrollers with ARM processors (EFM32, NRF52, STM32) | IAR for Embedded C, Eclipse IDE | Code for a specific task is reviewed before being merged into the main development branch. | 11-30 seconds | 30% | 40% | 30% |
Show |
| unit/system tests | arm based with multi core | arm ds5 ..... | swarm | 1-5 minutes | 60 | 30 | 10 |
Show |
| Write a test code to test new functionality. Regression test runs verytime before submitting new code. | ARM embedded system. | Eclipse cmake | Peer review | 1-5 minutes | 40 | 40 | 20 |
Show |
| ctest u-blox test harness | 4-5 ARM cores, embedded, flash file system, proprietary RTOS, communications applications. | ARMCC, gnuc, vi, ctags, perforce, swarm. I'm very old skool. | We use Swarm, and do it online. Usually 3-5 reviewers. | 1-5 minutes | 35 | 25 | 25 |
Show |
| Depending on the problem, I work to a predefined API, create the framework and then write a test to exercise this API. Fixing as problems occur. Or start working on a problem, developing / optimising the code and then write the test to exercise the final API, fixing as problems occur. | multi-core ARM based modem | Eclipse Jtag debuggers Software emulators | Use Jira to invite multiple interested parties to look over the changes. Typical reviews rely on trusting that the originator has passed regression tests | 5-30 minutes | 50 | 25 | 25 |
Show |
| Handcrafted unit tests in custom real-time and hardware emulation environments | Custom multi-core ARM/DSP/Hardware based SoC | MSVC ARM Eclipse | Using Swarm | 1-5 minutes | 40 | 30 | 30 |
Show |
| Visual Studio simulation to step through the code to verify functionality, followed by running a regression test suite prior to commit to ensure nothing is broken. | In house designed embedded multiple uProcessor with dedicated hardware for DSP algorithms. | Simulation of target processor h/w developed in-house to verify code will work work on the target h/w. | Short and casual! | 11-30 seconds | 50 | 30 | 20 |
Show |
Make this into a word cloud
Select text below (triple click), copy, then try one of these tag cloud generatorsjasondavies word cloud generator - colorful
tagcrowd - lets you show counts