Posts

Showing posts with the label testing

Management Tactics for the real world complex projects

A lot of management practices are used to optimize to current state of the projects and get the situation under control, but it does not always work as intended. Unfortunately, many people think that just applying the required process does the trick, however, in many cases it does not. I've published the presentation Management Tactics regarding that, and you can find the corresponding notes with the detailed explanations below.

Emulating line-buffering mode (Gradle example)

C printf() function doesn't flush buffers by default, and a lot of code using it may miss this, therefore creating interactivity problems to the end user. It's not specific to C though - it's about the standard I/O streams, and the problem may appear anywhere. The post is based on StackExchange discussion, so you can dig deeper if you want:  Turn off buffering in pipe .

Gradle task for launching Android simulator

Android build toolchain, albeit being powerful, sometimes lacks some essential functionality required for the modern software development. In particular, running instrumented unit-tests in the CI environment: those tests require a device or a simulator running, however developers need some scripting to make it work. To simplify the task, I've created a Gradle task that verifies if any Android device or simulator is connected. If not, the task launches a simulator with the first AVD in the list (or fails if no AVDs are found). It's up to you to make the dependencies for the connectedCheck task. The sample output: > ./gradlew connect --info ... :AndroidSampleApp:connect (Thread[main,5,main]) started. :AndroidSampleApp:connect Executing task ':AndroidSampleApp:connect' (up-to-date check took 0.001 secs) due to:   Task has not declared any outputs. Detecting devices... Launching emulator for Nexus_5_API_25 ... :AndroidSampleApp:connect (Thread[main,5,main])...

C modules unit-testing in Linux

Image
In spite of its age, C programming language is still very popular, especially for developing system or low-level software like drivers, compilers, virtual machines etc. And as any software, it have to be tested. Let me show brief introduction in unit-testing for C modules. There are many unit-testing frameworks for C, and one of the most well-known is cmockery . But I'll show the usage of much more simpler "framework" - FCTX . The main advantage of it is that it consists of just one header file, so it can be easily used for test tasks, small projects and examples. For calculating code coverage I use gcov / lcov tools. Gcov is included in GCC, so you don't have to install it. Lcov is a graphical front-end for Gcov and should be installed from the repository: $ sudo apt-get install lcov As a sample code for testing I'll use a simple hash function from Robert Sedgwicks Algorithms in C book: #include "hash.h" unsigned int RSHash(char* str, uns...

Geek Desktop Solution project

Image
In my free time I have started working on the new GPL project named "Geek Desktop Solution" (GDS). The project is a desktop (like KDE or GNOME ) aimed for keyboard jedi and other technical geeks. It was inspired by SciFi movies especially "Stargate Atlantis" . Rodney McKay, Chief Scientific Officer of the Atlantis Expedition, created his programs (or macros as it was called in the movie) interactively and very fast. I thought how it can be done and found a solution that makes this interactive and fast programming possible. The main concepts of GDS are: All environment items can be programmatically modified by user. The interactive shell is an entry point of the desktop - all operations can be performed using the shell. There is no mouse requirements - the user can operate the desktop using shell or keyboard shortcuts only. But at the same time almost all operations can be performed with the mouse (for touchscreen-based devices without keyboards)....