Old stuff, very old

Test design

Our test system has a pretty simple configuration, so I do not want to bother you with the detailed description of it. Simply - it's just a standalone execution of a test.py file with all requirements (test setup and tear down) in local internal test utility. Helper local utility has a usual amount of preparation functions, test data loading and some other configurations. In the very end of test loading, it just compares a node-set result of "real" scan (software and hardware nodes in a database after the scan) with predefined node-set (from test.py). Node set we usually expect at the end of the test should be added by the developer when product discovery pattern is ready or have a new feature or fix.

Now I'm trying to implement entirely new and somewhere different test design because current is not …

Old stuff

Morning everybody…

I recommend reading this part of the blog only in the morning with a cup of dark and strong coffee.

I'll show you some new cases, and howto's to help you automate routines in the developer's life. There will be an example of my fails and win on different scenarios. The poor code I'll include also.

Very beginning

Firstly - I'll try to make this thread in English. And maybe later when I have time - to make Ukrainian and Russian translations, I'll make them.

"Octopus" story has started from a small plugin for Sublime Text editor. Later it will be ported to Atom.

I've started developing "Octopus" on spring-summer 2016, and I've not finished it yet! New functions and features were implemented continuously. Product transforms into a framework.

Now all processes executed automatically and simultaneously for 24/7.  "Octopus" has …

Вкратце: когда добавляешь пачку тасок на Celery worker'ы, случается так, что парочка из них отваливается или засыпает или еще чего. Долго не доходили руки поправить это недоразумение, поэтому я просто рестартовал все воркеры раз в пару дней или прямо перед началом проверки рутины, в общем очень сложно было поймать и воспроизвести тот случай, когда без каких-либо ошибок воркер просто молчал. И наконец дошоли руки запилить кривофикс, время покажет насколько он толковый, суть в следующем: В сразу после момента определения свободного воркера  - запускать app.control.heartbeat() и app.control.ping(timeout=10) и если ответ пришел (в виде [{'alpha@host': {'ok': 'pong'}}]) - значит воркер готов и можно передавать ему таску, пачку тасков, рутину и тп. Если ответ пришел отличным от этого - даем ошибку и ничего не запускаем далее. При плохом раскладе пользователю придется просто перезапустить задачу посредством нажатия кнопочки еще раз, а вот запланированная таска - умрет. Общий вид на код примерно такой: ^{Набросавши …}

Have an interesting case I want to share and save for future. One small problem in this system: https://github.com/trianglesis/BMC_TPL_IDE is showing when some process is running and was not hanged up. Sometimes we need to run a huge amount of checks and tests and would be great to know if something hangs before killing it mannually. I used different scenarios and mostly a module pregressbar2, and this is what I finally can compose:

1. Make worker which will execute job sorf of randomly:

   1. import time
      import random
      
      print("START SOMETHING")
      
      for i in range(5):
          sec = random.randint(1, 3)
          print("Sleeping for: %d" % sec)
          time.sleep(sec)
          print("Making job, line: %d" % i)
      
      print("END SOMETHING")

2. Make process executor:

   1. import sys
      import subprocess
      import progressbar
      
      # Draw spinner:
      bar = progressbar.ProgressBar(max_value=progressbar.UnknownLength)
      
      # Execute some job with multiple lines on stdout:
      p = subprocess.Popen("C:\Python34\python.exe worker.py", shell=True, stdout=subprocess.PIPE,
                                                                           stderr=subprocess.PIPE)
      # Lines will be collected in list:
      result = …