Decide on Testing Targets for steem-python

[cyon1c]

Current testing coverage sits at 30% for steem and 57% for steembase.

Sensible targets should be set for improved test coverage.

Doneness: Testing Targets in the form of some metric (coverage/number of tests, etc) set for library.

[cyon1c]

@sneak - any input would be great. @roadscape - what is your testing philosophy/strategy for hivemind currently? @john-g-g - Same question for you, but for sbds

[roadscape]

It seems core functions are split between steem and steembase, unfortunately. @cyon1c do you have stats on coverage per file? If we want to use % coverage it won't make much sense unless we cherry-pick the critical files.

steem-js has a good testing model: https://github.com/steemit/steem-js/tree/master/test

  steem.auth: Crypto
    ✓ sign (2066ms)

  steem.auth: derives
    ✓ child from public
    ✓ child from private (50ms)

  steem.auth: key_formats
    ✓ Calcualtes public key from private key
    ✓ Create BTS short address
    ✓ Blockchain Address
    ✓ BTS public key import / export
    ✓ PTS
    ✓ To WIF
    ✓ From WIF
    ✓ Calc public key
    ✓ BTS/BTC uncompressed
    ✓ BTS/BTC compressed
    ✓ BTS/PTS uncompressed
    ✓ BTS/PTS compressed

  steem.auth: all types
    ✓ from object
    ✓ to object
    ✓ to buffer
    ✓ from buffer
    ✓ template
    ✓ visual check

  steem.api:
    setOptions
      ✓ works
    getFollowers
      getting ned's followers
        ✓ works (1204ms)
        ✓ the startFollower parameter has an impact on the result (366ms)
        ✓ clears listeners
    getContent
      getting a random post
        ✓ works (176ms)
        ✓ clears listeners
    streamBlockNumber
      ✓ streams steem transactions (3646ms)
    streamBlock
      ✓ streams steem blocks (7037ms)
    streamTransactions
      ✓ streams steem transactions (398ms)
    streamOperations
      ✓ streams steem operations (386ms)
    useApiOptions
      1) works ok with the prod instances

  steem.broadcast:
    ✓ exists
    ✓ has generated methods
    ✓ has backing methods
    ✓ has promise methods
    patching transaction with default global properties
      2) works
    downvoting
      3) works
    voting
      4) works
      5) works with callbacks
    customJson
      6) works
    writeOperations
      ✓ receives a properly formatted error response (250ms)

  steem.broadcast:
    comment with options
      7) works

  steem.auth: memo
    ✓ plain text
    ✓ encryption obj params (171ms)
    ✓ encryption string params (113ms)
    ✓ known encryption (65ms)

  steem.auth: Number utils
    ✓ to implied decimal
    ✓ from implied decimal

  steem.auth: operation test
    ✓ templates
    ✓ account_create

  steem.auth: types
    ✓ vote_id
    ✓ set sort
    ✓ string sort
    ✓ map sort
    ✓ public_key sort
    ✓ type_id sort
    ✓ precision number strings
    ✓ precision number long

  52 passing (27s)
  7 failing

[cyon1c]

@roadscape output from the pytest-cov plugin.

[cyon1c]

@roadscape I agree that I like steemjs' testing model. Been trying to find some good resources to detail different methods of testing code coverage - I haven't found a whole ton, but from a gut check, lines of code coverage doesn't feel as though it is an honest indicator, as their may be multiple corner cases that aren't handled even though a method is "covered". I'm going to spend a little more time looking at steemjs' tests and start to explore that rabbit hole.

[cyon1c]

@john-g-g & @sneak

If this approach of feature based coverage sounds solid, then I'm going to close this issue and put issue #167 into the proposed backlog for next sprint.

[cyon1c]

@sneak @john-g-g Would love your input before I close this issue out for the sprint.

[sneak]

I am fine with feature-based coverage for now.