Curiosity Blog

Summary: code snippets and explanation of how to validate HTTP-response using  openapi-core package If you deal with some service based on OpenAPI Specification you might want to perform validation of HTTP responses returned by it. One of the ways to do this an internet search provides for Python is to use openapi-core package. If you look at their documentation ( here or here ) you will find it very stingy: couple of short code snippets and couple of sentences just stating what is done. In particular for response validation we have exactly the following:   You can also validate against responses   from openapi_core . validation . response . validators import ResponseValidator   validator = ResponseValidator (spec) result = validator . validate (request, response)   # raise errors if response invalid result .raise_for_errors()   # get list of errors errors = result .errors ...   Here we see some confusing things: why do we need a request object to be able to validate the respo

Example of how to check some conditions when ALL test suites finished (or enforce some test running at the end of session). This may be useful to ensure that you have tested all functions of some module whose interface can change in future. The code: from   pytest   import   fixture     Data  =  dict ( cnt  =  0 )   @fixture ( scope = 'session' ) def   data_0 ():        yield   Data        # (this will be done AFTER all tests below)      assert   Data [ 'cnt' ] ==  3 ,  f 'data-cnt:  { Data [ "cnt" ] } '   @fixture def   data ( data_0 ):        Data [ 'cnt' ] +=  1        return   Data [ 'cnt' ]   def   test_11 ( data ):        print ()      print ( 'test-11:' ,  data )   def   test_12 ( data ):        print ()      print ( 'test-12:' ,  data ) Output: ERROR test_1.py::test_12 - AssertionError: data-cnt: 2 _________ Other articles ~ programming

 Working  on his theory of inventions  Genrich Altshuller  invented/discovered so called  Laws of technical systems evolution  which further were developed by other contributors. Looking at those laws we can see that all of them are in some sense “positive” — i.e. implicitly assume that technical systems always develop from “worse” to “better” only. BUT from my experience I can conclude that the things are not so simple. For example: in 2000ths I used several button-based “stupidphones”. They could do almost nothing except the very basic functions a phone in general is necessary for. And of course it was very unsatisfactory. But when I changed to use “smartphones” I soon was faced with very disappointing obstacle: when I set an alarm on a “stupidphone” and it happens that the device is low on power it still is able to awake next day to activate the alarm and perform ringing even if it turned off due to a complete discharge of the battery before. Very helpful feature. And no modern devi