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? | |
|---|---|---|---|---|---|---|---|---|
| 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 |
| Most of my project history is embedded oem projects where I am the hardware and firmware engineer. The firmware tests are functional when bringing up a board. When writing the application firmware the testing is done with some rough data simulations and then validated on the machine itself in our lab. As features are added the firmware is sent to customers so they can begin using their equipment and provide feedback. | Typically embedded boards with 32bit microcontrollers. I also work quite a bit on embedded ARM Linux platforms. | Visual Studio MPLAB Atmel Studio QT Creator | Before a project starts or a new complicated phase I will have architecture reviews with another engineer to get second opinions on my intended approach. On collaborative project reviews would happen before a release. | 11-30 seconds | 50 | 25 | 25 |
Show |
| Lots of hands on testing. Make a change, test it. | Arm Cortex M0+ and M4 | MPLABX, SEGGER, NXP, Logic Analyzer, Oscope, DMM | Code reviews are test driven and informal. | 11-30 seconds | 30 | 40 | 30 |
Show |
| Debuggers - test code | Embedded Linux | Linux VM, Eclipse, cross compilers, GDB | Look for patterns to fix. memory leaks, potential errors, some static analysis | 1-5 minutes | 30 | 50 | 20 |
Show |
| Debugging on a device. Our required IDE for PLC development does not allow code to run unless loaded on a device, so we have to load it on a device and debug in order test the code. In the past I have attempted to translate the ST code to C# to help develop some functionality, but testing the C# code not mean the ST code does not have any issues. | I write code for a PLC (iPro). | Custom version of ISaGRAF as the IDE and StarTeam for VSC. For my hobby, I also use VS Coe and Visual Studio with their tools like nuget, git, etc... | Not frequent and we don't often have the time or knowledge on a project (3-4 devs working on 3-4 projects) to do thorough reviews. It is often only reviewing code that has issues. | 1-5 minutes | 30 | 70 | 70 |
Show |
| Debug sessions and manual testing | Most of my target systems are small microcontroller-based systems. Some are connected (BLE, Wi-Fi, USB) and some are stand-alone instruments. | Simplicity Studio Notepad++ Visual Studio MPLab X Android Studio XCode | I have not had any code reviews, as I have historically been the only software developer on the projects I have worked on. | 11-30 seconds | 20 | 50 | 30 |
Show |
| Make a development build and bench test it. | I primarily work on our SS/E3 platforms they are a building control system for HVAC, Refrigeration, and lighting | Eclipse | I schedule a meeting with my team and walk through the changes I made to the code. During the walk through I explain my thought process on why I made the changes I did. | 5-30 minutes | 50 | 10 | 40 |
Show |
| manually | Embedded Device | Visual Studio Code | Ad hoc | 11-30 seconds | 70 | 20 | 10 |
Show |
| In association with the hardware. | Microcontrollers. | QT. STM Cube, | Peer reviews. | 1-5 minutes | 60 | 25 | 15 |
Show |
| Most test are done by testing with hardware and hardness. Few tests are done by some software unit test. | it is a system, with a control software, a gateway and control boards. The cloud will be included in the near future. | MS Visual Studio, and Eclipse Editor. | Sometimes I do, sometimes not. But I prefer to do it. To check the logic needs some more thoughts or not, and coding is efficient or not. | 5-30 minutes | 1 | 7 | 1 |
Show |
| not very well | linux | visual studio 2017, 2019, 202+, Eclipse IDE, intelliJ | have had a few, but not very many. | 11-30 seconds | 60 | 30 | 10 |
Show |
| Running it against real data | Wi-Fi IoT device, embedded 802.15.4 devices, mobile devices, and cloud systems | As a manager... excel, windows, etc. | N/A | 5-30 minutes | 0 | 0 | 0 |
Show |
| Custom unit test and functional testing are my primary test methods. I also occasionally use UART prints to log things for longer tests. | ARM processors | code composer by TI, CubeID by ST, Eclipse | 2 to 3 engineers participate in reviews. For changes we use beyond compare to identify modified code sections and those are reviewed in a meeting with peers. | Under 10 seconds | 60 | 30 | 10 |
Show |
| Unit test with Debugger Automated tests using serial port to inject data. | Mostly STM32 mcu | IAR Workbench J-Link debugger | We have mostly offline peer review to verify that the developper did not do any obvious mistake and the the code is consistent with the design. | 1-5 minutes | 6 | 2 | 2 |
Show |
| single step, use print statements, use an app to check functionality | various microprocessors | Keil, Visual Studio, Eclipse | use online code reviews where everyone can comment on the code | 1-5 minutes | 3 | 5 | 2 |
Show |
| Ad-Hoc test using debugger. Write simple test code or scripts along with developed code, but not systematically done. | Embedded IOT device with cellular, WIFI, Bluetooth connectivity | Eclipse-based compiler, debugger. Infrequent use of Google-Test. | Use JIRA to review most if not all changes and features. | 5-30 minutes | 90 | 10 | 10 |
Show |
| Some level of unit testing, white box testing (single stepping) and functional testing | Mostly work on developing autopilot systems for small drones. Largely use STM ARM Micro-controllers running u-COS. Also embedded Linux | Visual Studio, Eclipse, Keil uVision. | Use Crucible and Git for code reviewing depending on the code base. Crucible is most widely used but we are trying to migrate from SVN to Git | 31-60 seconds | 50% | 20% | 30% |
Show |
| Test after development | Lock system | Python, Testrail | n/a | 5-30 minutes | 0 | 100 | 0 |
Show |
| Write unit test. | Single board computer using a STM micro. | IAR tool chain. VScodium editor. | Usually with one other person. | 31-60 seconds | 90 | 3 | 7 |
Show |
| For our C code, alot of times we have done manual unit testing, or pseudo-automated, more as the real device. | Embedded Fw running on ultra low power micros, such as ST micros. | Visual Studio C++ for Sw Apps, IAR Ide for Embedded Fw | We review C code for functionality, coding style, correctness on a regular basis. | 1-5 minutes | 40 | 40 | 20 |
Show |
| With console printouts, debuggers, and analyzers | I am coding for a circuit controlled by an stm32 microcontroller | IAR embedded workbench, saleae logic analyzers | I am new to dormakaba, and have not yet had a code review. | Under 10 seconds | 40 | 20 | 40 |
Show |
| Manual techniques: print statements, log files, observing behaviors, using a debugger if the IDE allows | Embedded firmware in door locks and controllers. Operating systems are a combination of Linux, FreeRTOS and bare metal | Eclipse, Visual Studio, vi | Currently: Informal meetings, 2-3 participants Future: GIT pull requests | 1-5 minutes | 50 | 30 | 20 |
Show |
| develop/execute unit tests manually. Separate team does functional and integration testing. Mostly manual but have developed automated testing for some projects. | Most of our products are embedded systems that deal in access control. Locally, our product line focuses on safe locking systems. | IAR IDE, Visual Studio, others | peer reviewed | 1-5 minutes | 40 | 30 | 30 |
Show |
| Since we ( my team ) are not developers we don't deal with unit testing. We design and implement regression testing using frameworks such as Selenium, FitNesse | Windows. Android | Visual Studio | Mostly I am concerned with use cases and how best we are covering them as oppose to coding standards. I leave that to my senior SW team members | 1-5 minutes | 20 | 30 | 50 |
Show |
| Developers use Brute force, Product Assurance (PA) does black box testing. | IAR - STM32, MSP430 | IAR, VSCodium, Meld, AStyle, Git (migrating from SVN). Visual Studio 2019, Corporate provides Git, Jenkins, Sonar Qube | Up to this point had Subversion as VCS, are now in process of migrating to Git. Once we are on Git will be using pull-requests for code reviews. Up to now it was by using a patch or by examining changes once committed. | 31-60 seconds | 6 | 2 | 2 |
Show |
| Unit test with CppUTest. | Gecko Micros | Docker, various IDEs, virtualization (VmWare, VirtualBox) | We conduct code reviews in Bitbucket. | 1-5 minutes | 20 | 15 | 30 |
Show |
| Initially when setting up communications - extensively use logic analyzer. Usually standalone test apps for other tests - to check data input crcs, frequency etc. | Usually ARM based microcontroller (Mostly ST - F4, F7) projects. | Uvision Keil, Visual studio, Eclipse | Usually we would do SVN Diff for modifications and do an informal review. We have started migrating to Crucible for formal reviews. It can pull the changes from SVN and track code review comments which are marked as unresolved until resolution. | Under 10 seconds | 40 | 30 | 30 |
Show |
| Run on simulator to check basic functionality since it's easier to control the environment. Then load and test on hardware to exercise the code. | Embedded Linux on Xilinx Zynq, running on small air vehicle. | Visual Studio, Keil IDEs. Git/Gitlab for source control and code reviews. | Performed in gitlab by peers of varying experience levels. | 1-5 minutes | 50 | 30 | 20 |
Show |
| I have a small legacy project in C#, that I was able to recreate the core using TDD and NUnit, also tried to apply SOLID, TDD guided by ZOMBIES and other advises from you, Uncle Bob and Martin Fowler. My main project, who pays the bills, is in Harbour, which does not have a Test Harness nor Code coverage. I'm currently writeing a free, opensource test harness for it inspired by CppUTest, JUnit, NUnit and xUnit. | Mostly Linux and Windows desktop. For embedded I experimented with ESP8266. | JEdit, VsCode / Visual studio community, docker, subversion, git, virtualbox | I do a lot of pair, even before hearing about agile. So I avoid later code reviews as much as I can. And I always have a tight relationship to the user to avoid misunderstandings. | 5-30 minutes | 25 | 25 | 50 |
Show |
| Unity for unit testing and a hardware in the loop test with inhouse python scripts. | A terminal using a stm32 mcu sending data from satellites. | arm-gcc, cmake, unity, cppcheck. | If the pull request is small, we found something to say. If the pull request is huge, sometimes, we juste accept it because it's too complexe to understand. | 5-30 minutes | 70 | 20 | 10 |
Show |
| Unit Testing, low-level functionalities on embedded hardware (manual runs) and high-level functionalities on x86 HAL (partial emulation) in CI Integration testing with test procedures remotely commanding embedded software and verifying result of execution. Partial integration testing with software running on x86 emulation. | Spacecraft subsystems, either FRAM-based MSP430 (12Mhz, ~40KB firmware size, ~12KB data memory), or Cortex-M3 (100Mhz, ~64KB firmware size, 64KB RAM). | Visual Studio with VisualGDB extension GCC toolchains (x86, MSP430, ARM) and VC++ (x86) | Through pull requests for major features, not always for smaller. Lot of room for improvements. | 11-30 seconds | 50 | 20 | 30 |
Show |
| On device testing/verification | We develop on a variety of microcontrollers like the MSP 430 and 8051 chip | IAR | We user PRs where our team members will review and approve PRs | 5-30 minutes | 20 | 50 | 30 |
Show |
| separate binaries and test scripts | Linux on ARM SBCs, PIC Microcontrollers, and getting into ARM STMicro chips soon as well. | Visual Studio, VS Code, QTCreator | We typically do these ad-hoc, with usually 1 reviewer. | 31-60 seconds | 40 | 20 | 40 |
Show |
| Unit tests, higher level functional tests, benchtop simulators that mimic the ocean in some small way, systems tests in our test tank, test at sea. | Various ARM processors, currently developing a STM32H7A3 based system. Not a lot of heavy duty computing but we do need to run control loops at a deterministic rate (usually less than 100 Hz). And we have to interface to a lot of instruments. | Visual Studio | I grew up as an engineer at a defense contractor where design reviews of all kinds were a critical part of my job. I've been at MBARI, an academic oceanographic research institute, for 25 years and formal design reviews are not so effective. | 11-30 seconds | 20 | 50 | 30 |
Show |
| Unit testing, functional testing. | - | - | Done through Bitbucket, all team members are always included, requires a minimum of 2 approvals. | Under 10 seconds | 40 | 50 | 10 |
Show |
| Unit testing with Unity/FFF. Tests are generally written after the code. Tests are built into our CI pipeline to be run on commits. We also have Hardware In the Loop testing for integration level testing | STM32L5 M33 based hardware; bare metal finite state machine based application; GCC/CMake toolchain; The product is a micro linked to a custom ASIC radio chip over SPI | GCC, CMake, CLion, Azure DevOps | We generally work in feature/bugfix branches, and then do PRs in master branch. The PRs need to be reviewed by the 2 other firmware engineers in the team. The obvious weakness to me is the lack of focus on "how good are these tests" in the review. | Under 10 seconds | 4 | 2.5 | 3.5 |
Show |
| I work mostly in mobs. Most of my coding in my current job is during katas. We use TDD with cyber-dojo. I would like to take TDD katas to the embedded world. The embedded developers in my area do MIL/SIL testing. There also are validation teams upstream who do a combination of manual and automated testing. | The area I work in develops Autosar based C code for embedded vehicle ECUs. 70% is model based, 30% is hand coded. | Matlab, Embedded Coder, Simulink,BTC Tester, Target Link | Peer code reviews are a mandatory step for all code. They also review models and data dictionaries. | 1-2 hours | 50 | 25 | 25 |
Show |
| Unit tests, run the code use the device (user perspective) | CubeSat | VisualStudio, Visual GDB | While reviewing git pull requests (MS DevOps) | 11-30 seconds | 50 | 30 | 20 |
Show |
| For re-usable/library code I use Ceedling to do some unit testing, but it has been difficult to find a way to use this on our production code. Most SW testing is manual bench testing with a debugger, and integration/system testing in the product. I've used Robot Framework with python to do some automated integration tests on our products, but I would say that the majority of testing is done using a debugger or python scripts. | The products I work on are embedded controls for electric motor protection devices or variable frequency drives. We run on bare metal with a cooperative scheduler. | Vendor-provided Eclipse-based IDEs and build tools with various debuggers depending on the target. I use python for writing test scripts/tools. I use vim for more involved coding (I use Windows Subsystem for Linux to get vim and other Linux tools). | I use Microsoft DevOps to do code reviews via pull requests with git. Typically I look at diffs if I am familiar with the codebase, or I will look at the whole files more if I am not familiar with the code. | 31-60 seconds | 20 | 30 | 50 |
Show |
| We are doing two "types" of tests. Unit tests and Continuous integration tests. Unit tests are done by the Software Engineers when we add some code. Continuous integration tests are done by our Test Engineer. | Our application runs on a STM32L5 MCU. We also ported it to x86_64 to facilitate the unit tests. | Visual Studio Code on Ubuntu STM32CubeIDE STM32CubeProgrammer Azure DevOps | Usually we do a PR with several code reviews. We put comments where we want discuss something and when we agree on everything, we accept the PR. | 31-60 seconds | 55 | 15 | 30 |
Show |
| After having written a code following a phase of planning, I write unit tests for the code and try to cover the possible outcomes of software units as extensively as possible. | Nano-satellite subsystems powered by constrained hardware with space flight heritage (TI MSP430, some STM32 architectures). Used to working against code size limitations, to favoring deterministic behavior, and efficient CPU/memory usage tradeoffs. | Git, IAR Embedded Workbench, Visual Studio, Visual GDB, GCC, Logic analyzers, Oscilloscopes, Matlab | They are usually only done when examining pull requests to the main development branch following the development of a feature. | 11-30 seconds | 20% | 20% | 60% |
Show |
| behave off target testing + on target (+ unity) | various m0 / m2 boards | IAR workbench, VM, scons, atlassian tools, git | pull request in git reviewed by 2+ other developers | 5-30 minutes | 30 | 40 | depends |
Show |
| Generally compagny I worked don't use unit test. When I'm free I try to use TDD and gtest but I think knowledge are missing to do it right. | I work mainly on the gui, so I cannot goes in details about the system. | vim, linux command line, tmux... Qt creator to be able to debug it. | ON this compagny code review is new, so not so much. On my previous job, I was lead developer, so I introduced code review. OUr quality increase a lot. The time to develop a feature grows by 40/60% but the bug report decrease to 80%. | 5-30 minutes | 3 | 1 | 6 |
Show |
| Using Unit Tests to verify that my code still works after changes have been made | cooking device with a modern user interface to provide an easy and automated experience for preparing meals in the commercial sector | QT Framework | Usually done in gitlab over merge requests | 11-30 seconds | 60 | 10 | 30 |
Show |
| write unit tests | / | QtCreator | i've used Pair Programming, Over-the-Shoulder and Merge-Request to help reviewing codes | 1-5 minutes | 5 | 2 | 3 |
Show |
| Predefined Test cases. | Embedded Linux | Visual Studio Code | - | 5-30 minutes | 40 | 20 | 40 |
Show |
| As Qt is platform independent, tests by the developer are ususally done in a simultation environment on a Linux Server. That is fast an convenient. Only after successfully testing the code, the code is cross-compiled and flashed onto the embedded target device. | Embedded Linux, ARM CPU, | Everything provided by Qt (Qt Creator, Qt Designer, QML Profiler etc) Valgrid, Lint, Jenkins, Git, Gitlab pipeline | Very new. Not entrenched in mindset. Is seen by some as a hassle. But that is the wrong attitude. Code reviews can not make sure code is error free, but helps with architecture, style and grave mistakes. | 11-30 seconds | 70 | 10 | 20 |
Show |
| Unittests and AcceptanceTests | Qt/QML UI, C++ backend, Python system tests | VSCode, PyCharm, QtCreator | Currently at least 1 reviewer and the gitlab pipeline. Sometimes also pair reviews. | 11-30 seconds | 50 | 30 | 20 |
Show |
| I am working most on legacy code, try to write some kind of unit tests to prevent regressions. | Embedded System, working with C++ / QT / QML | QtCreator / gcc / clang (code analysis), git, | We started doing merge requests with coding reviews | 11-30 seconds | 40 | 20 | 30 |
Show |
| Write test cases with Qt Test framework. | Yocto based Linux on ARM | Qt-Creator Clang-Tidy and Clazy | Review over Gitlab MR | 1-5 minutes | 30 | 30 | 40 |
Show |
| QTest, screenshot comparison | Embedded linux | QtCreator, Visual Studio | git lab merge request. I prefer gerrit | 1-5 minutes | 30 | 20 | 50 |
Show |
| Most of testing is done by manual testing. Few unit and integration tests (via QtTest) are written. But it doesn't cover full code. | Target system is under UNIX system. We have two main applications (frontend/backend) running and communicating between each other. | QtCreator CMake | We use merge request via Gitlab to validate or not modifications. At least two MMI members are put as reviewer. | 1-5 minutes | 30 | 40 | 35 |
Show |
| Manual testing, unit tests with qTest | embeded linux with touch screen | QTCreator | - | 11-30 seconds | 60% | 20% | 20% |
Show |
| If applicable I try to write tests preemptively after creating a class skeleton/interface for example. As a seconds step fill it with the actual functionality and see if it fulfills the requirements. | Embedded Linux | Qt Creator, VS Code, Visual Studio | Gitlab merge requests. If required, face-to-face / via video call) | 1-5 minutes | 50 | 25 | 25 |
Show |
| mostly manual with defined test procedures and unittest | Commercial kitchen cooking appliances | C++ Builder, DBSchema, QtCreator | rare | 5-30 minutes | 50 | 30 | 20 |
Show |
| using small unit tests, debugging code with print-outs | Our target consists of three parts of : basis, cooking system&application and mmi running on a linux machine | VS Code gitlab | every bigger change is review by a merge request | 11-30 seconds | 30 | 20 | 50 |
Show |
| testing on the machine using test cases; using logging outputs | its a linux machine | qt creator | sometimes I'll do a review with a colleague | 11-30 seconds | 60 | 10 | 30 |
Show |
| Highly dependent on the project and on the customer's wishes and needs. | -- | VS Code Qt Creator IntelliJ | Highly dependent on the project and on the customer's wishes and needs. | 1-5 minutes | 33 | 33 | 33 |
Show |
| i am testing my components either on a Intel-PC, or in a kind of simulation on the target. | arm-single-core controller, linux, 2 main processes running (mmi and base), too less RAM, too less computing power,... | tools provided by the OS, QT-creator, geany, gdb,... | we are designing components of the cooking oven. The collaboration in our system is the part, causing problems because in many cases the behaviour of these components cannot be foreseen. The big issue is not the SW, but the system behaviour... | 1-5 minutes | 20 | 40 | 40 |
Show |
| - manually - some qtest module tests | - embedded device | qtcreator | are in planning to do | 1-5 minutes | 33 | 33 | 33 |
Show |
| Mostly by hand, because big chunks of the code are not testable apart from other big parts. | weak hardware ARM device | QtCreator, MySQL Workbench, Python- and Bash-Scripts | Code Revies must not be done, but for middle to big changes i use them with other experts of this code modules. Usually I tell the colleagues how it should work and they comment. If needed, we do multiple rounds. | 11-30 seconds | 50% | 25% | 25% |
Show |
| I am using google test. To bring the system in the right state and set the needed preconditions is most challenging for me. Furthermore, the test converage could (as always) be improved but lacks of setting up the test. | embedded linux with ARM processor | QtCreator | My colleague and me are doing regularly code reviews on the component we are developing. It helps us a lot and it would be great if we have more of it in the whole project. First attemps are made by introducing merge requests. | 11-30 seconds | 40 | 20 | 40 |
Show |
| When starting new feature: write Code with public interface, write gtest unittests for "happy path", write some more error/edge cases. If extending existing untested class: run executable on desktop and target. | ARMv7 single core with Yocto Linux | Visual Studio Code, remote ssh plugin, C++ plugin, Test Explorer UI plugin | We actually started doing those in the past year. I submit a MR in gitlab and get valuable feedback from my domain-colleagues | 11-30 seconds | 50 | 20 | 30 |
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