Open Rfp-10: Wallet Rpc Test Coverage #1

Discussion in 'Requests for Proposals' started by jy-p, Jun 23, 2016.

  1. 2017/12/15 - Decred v1.1.2 released! → Release Notes  → Downloads
  1. jy-p

    jy-p Sr. Member
    Organizer

    Jan 2, 2016
    133
    340
    Male
    Note: This RFP is open to everyone. Please submit a proposal if you are competent in this domain and interested in performing this work. If your proposal is accepted, your work will be paid for in DCR as the work is completed. Please send all proposals to: rfp2016 <at> decred.org

    Closing Date

    All proposals must be submitted by 6 PM UTC July 8th, 2016.

    Description
    In order to prevent regressions with RPC calls and provide quality assurance for users of dcrd and dcrwallet, behavioral test coverage is required. The test coverage will be implemented in Go using the dcrrpcclient package and make use of an RPC test harness. This is the first of several RFPs that will address the RPC test harness coverage, and the focus will be on adding coverage for the most important and most frequently-used RPC calls.

    Requirements
    • Experience programming in Go
    • Experience writing test coverage
    Scope
    Since this is the first of several RFPs that address behavioral test coverage using an RPC test harness, this RFP will not cover all ~140 RPC calls. A subset of these RPC calls has been identified as those most frequently used by Decred users, so we will begin by adding test coverage for these RPCs. There are a handful of additional RPCs that did not make this list that are extremely important for the accurate functioning of exchanges and mining pools, and these are also included.

    All RPC calls will be tested using positive tests, and negative tests will be expected where they make sense. An example would be that a negative test for validateaddress makes sense whereas a negative test for getstakeinfo doesn't make sense. Tests will make heavy use of the dcrrpcclient package and require comments that make clear what each test is doing. The RPC calls to be covered in this RFP are
    • getnewaddress
    • validateaddress
    • walletpassphrase
    • sendtoaddress
    • sendfrom
    • sendmany
    • getbalance
    • listaccounts
    • listunspent
    • listtransactions
    • getwalletfee/settxfee
    • get/setticketfee
    • get/setticketmaxprice
    • get/setbalancetomaintain
    • purchaseticket
    • gettickets
    • getstakeinfo
    • walletinfo
    These tests will be run in series after a single simnet chain has been generated for testing. The RPC test harness creates a fresh simnet chain that is tested after it reaches stake validation height. Example tests for sendtoaddress and sendfrom have been included to provide some guidance on what will be expected. Keep in mind that testing one RPC call typically requires performing one or more other RPC calls in the process.

    Please contact the Decred developers in the #decred-dev IRC channel if you have questions about what is expected in terms of test coverage.

    Estimated Work
    2 weeks FTE or greater (1 FTE = 40 hrs/week).

    Proposal
    Proposals should include:
    • References to prior work with Go and test coverage
    • Estimated completion time
    Milestones
    Partial payments shall be made at the following milestones:
    • Complete test coverage for the following RPC calls: getnewaddress, validateaddress, walletpassphrase, getbalance, listaccounts, listunspent
    • Complete test coverage for the following RPC calls: sendtoaddress, sendfrom, sendmany, listtransactions, getalletfee/settxfee, get/setticketfee
    • Complete test coverage for the remaining RPC calls: gettickets, purchaseticket, get/setticketmaxprice, get/setbalancetomaintain, getstakeinfo, walletinfo
    Modification of these proposed milestones is acceptable, and must be accompanied by sound reasoning in a proposal. Under no circumstances shall payments be made in advance of work being completed.
     
    David, chappjc and tacotime like this.
  2. chappjc

    chappjc Full Member
    Developer Pool Operator (PoS)

    #2 chappjc, Jun 24, 2016
    Last edited: Dec 6, 2016
    Mmmmm, unit tests.

    While I'm fairly certain I can handle these tasks...
     
    jy-p likes this.
  3. ay-p

    ay-p Full Member
    Developer

    Dec 7, 2015
    148
    106
    Male
    What were you thinking? We always try to give our best estimate. If you think it'll take more time, let us know.
     
    chappjc likes this.
  4. jy-p

    jy-p Sr. Member
    Organizer

    Jan 2, 2016
    133
    340
    Male
    Do note that the estimated time required is 2 weeks FTE or greater, so the 2 week figure is just a lower bound, i.e. even someone very familiar with doing this work on this codebase should take about 2 weeks FTE. Remember that a proposal will include the cost that you think is appropriate for the work, so you're welcome to propose whatever you consider fair.
     
    chappjc likes this.
  5. @madferreiro

    @madferreiro New Member

    Dec 17, 2015
    5
    7
    Why is this still open? Does that mean someone can still apply?
     
  6. jcv

    jcv Full Member
    Developer

    The RFPs aren't really open any more (until we can rework them). There may still be contracting open though. Check out the other (non-RFP) recent posts in the RFP topic of the forum or join our slack if you want to know more.
     
    @madferreiro likes this.

Share This Page