Course code: CISCO-25
  • Years with company: 10
  • Years programming: 17
  • Primary programming language: c
  • Other programming languages: python c++
  • Unit test harnesses: pytest unittest cunit cpputest
  • Something else: I like new challenges and learning
  • Test practice now: We have three levels of testing We currently use CPPUtest for unit tests in the Swiss team but this is neither a recognized usage nor is it enforced or encouraged by the organization. The first official tool is called SWIFT which is an in-house built LUA unit test framework that uses FFI bindings to C code. Please note that although we considered it a unit test framework and it can certainly be used to test a single function it is currently used more as an integration test framework. The two levels above are whitebox tests. The last level uses PyATS which is a black box test framework exercising our external interfaces such as CLI, SNMP, Netconf/YANG, RestConf, ...
  • Target system: We are building a wireless controller which basically needs to configure and coordinate the wireless access points in a given deployment. We have 4 form factors: > appliance > embeded on switch > embedded in the AP > virtual
  • Dev tools: git for source control github enterprise for commt workflow different editors (vim/emacs/...) to the liking of the developper opengrok for code indexing many custom made tools for different tasks
  • Build time: 5-30 minutes
  • Coding standard: Use header guards Use enums not define If define use self indexing names No magic number Avoid conditional compilation use inline instead of macros declare prototypes Do not use __FUNCTION__, __FILE__, ... Avoid need for forward declaration
  • Function too long: Usually when I have to scrill back and forth to reload some context in my head to understand what a later piece of code in the function does. Another indicator would be if it fits on my screen. Yet another if I have to copy-paste.
  • Code reviews: Currently, we have a code ownership model in GitHub which enforced at the pull request. This ensure those subject matter experts get involved. That being said review gets lengthy so the focus of the reviewer might not be optimal.
  • Code time: 40
  • Test time: 20
  • Debug time: 40
  • Favorite thing about dev: The fulfillment of building new functionality that addresses a customer problem.
  • Least favorite thing about dev: When development practices do not enable fast development. Boilerplate code. Verbosity
  • Tdd knowledge: I am pretty positive about it but I think our current build system and code architecture are an impediment to it.
  • Why are you attending: To sharpen my skills as a developer as a first priority. To improve my development workflow as a second priority. To improve the product as a third priority.
  • Back