achow101 changed the topic of #bitcoin-core-dev to: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Weekly Meeting Thursday @ 16:00 UTC | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
PaperSword has joined #bitcoin-core-dev
Cory8 has quit [Quit: Client closed]
Cory8 has joined #bitcoin-core-dev
Cory40 has joined #bitcoin-core-dev
<dzxzg> with the PIMPL pattern for e.g. PeerMan and PeerManImpl, what is the philosophy for unit testing functions that are internal to PeerManImpl and don't need to be exposed through PeerMan? For e.g. the stale tip eviction unit test we export the internal function: https://github.com/bitcoin/bitcoin/blob/d5ed4ba9d8627f1897322ce7eb5b34e08e4f73ac/src/net_processing.h#L141-L142
<dzxzg> Is the answer to only test "public" interfaces?
Cory8 has quit [Ping timeout: 250 seconds]
<dzxzg> It just seems like esp. for peermanagerimpl, the scope of internal functions grows from a one-off utility to something with lots of users with various subtle expectations; to make it concrete, in the case of PeerManagerImpl::BlockRequested, would anyone object to continuing the approach of exporting stuff into the interface class just for the purpose of being used in unit tests?
Cory59 has joined #bitcoin-core-dev
Cory40 has quit [Ping timeout: 250 seconds]
<dzxzg> maybe this is just an argument for breaking stuff out of PeerManImpl into smaller chunks