Ninja robots
03-01, 15:30–16:00 (UTC), Gather Town

In my experience as a solo user with limited to no access to reviews, these tools and techniques allowed me to be successful, with purpose build keyword libraries

1.git, especially git bisect and log -S

2.advanced unit testing with pytest, xray, and hypothesis

3.measurable complexity with radon

4.Therefore orthogonally structured code


Ninja robots

I would like to discuss the possibility to substitute review with tools. Reviews are the better solution, this is to be used if for some reason reviews are not available.

Learn about the history of your code base.

"git bisect" plus "git log -S" is an efficient way to properly blame. Especially in a corporate environment, people tend to copy code and claim credit until it's a problem.
Using git log -S it is possible to find the earliest occurrence of a piece of code. This is especially useful with function names. This is a static code analysis approach
to explore a code base.

This may not give enough insight tough. Using git bisect it is possible to find the change that changed the result of a test from pass to fail or vice versa.
This is especially useful in situations in which a bugfix, creates another bug. This fulfills a similar purpose as log -S but experimentally.

This has advantages over communications as it brings hard facts, while it is easy to talk up a theory in a small group.

I would run through examples of both techniques using an open-source project as an example. Preferably robotframework itself, but I do not have an endorsement yet.
We will have a look at when a specific function was introduced, and how its popularity developed over time.

Measure whether your tests detect changes in your code base.

The theory is that given correct code that has at some place a "+", is very likely to become bugy when the "+" is replaced with an "%" for example.
This detects among other things, dead code, gaps in the test coverage, and vague specifications.

Ask the computer to check for the limits of an implementation

Does your function work with negative numbers? 0? Are there size limitations? using hypothesis it is easy to learn about these limits and ask a computer to check those limits.

Without a corrective it is easy to think that code is more elegant and easy to understand than it is.

By using radon it is possible to use the computer to provide objective feedback about the complexity of source code.

finally, we will see that points 2 and 3 are interconnected, and lead to

orthogonal structures

which means that functionality is created by composing simple building blocks, as opposed to inheritance, code injection, etc ...

  • 2013-present application engineering and validation/verification engineering at ams-osram
  • 2011 – 2013 home automation at intrate(c)
  • 2010 – 2011 RMA engineer at infineon
  • 2009 graduation at the university of applied sciences FH JOANEUM
  • 2007 – 2010 mixed signal ASIC development at FH JOANEUM
  • 2008 participation at the CERN Summer Student programe
  • 2001 – 2005 industrial automation at intrate(c)