2019-03-05 14:05:34 -07:00
|
|
|
# Copyright (c) 2014-2019, The Monero Project
|
2014-09-11 00:28:28 -06:00
|
|
|
#
|
|
|
|
# All rights reserved.
|
|
|
|
#
|
|
|
|
# Redistribution and use in source and binary forms, with or without modification, are
|
|
|
|
# permitted provided that the following conditions are met:
|
|
|
|
#
|
|
|
|
# 1. Redistributions of source code must retain the above copyright notice, this list of
|
|
|
|
# conditions and the following disclaimer.
|
|
|
|
#
|
|
|
|
# 2. Redistributions in binary form must reproduce the above copyright notice, this list
|
|
|
|
# of conditions and the following disclaimer in the documentation and/or other
|
|
|
|
# materials provided with the distribution.
|
|
|
|
#
|
|
|
|
# 3. Neither the name of the copyright holder nor the names of its contributors may be
|
|
|
|
# used to endorse or promote products derived from this software without specific
|
|
|
|
# prior written permission.
|
|
|
|
#
|
|
|
|
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
|
|
|
|
# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
|
|
|
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
|
|
|
|
# THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
|
|
|
|
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
|
|
|
|
# STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
|
|
|
|
# THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
#
|
|
|
|
# Parts of this file are originally copyright (c) 2012-2013 The Cryptonote developers
|
|
|
|
|
2016-08-29 10:12:19 -06:00
|
|
|
# The docs say this only affects grouping in IDEs
|
|
|
|
set(folder "tests")
|
2017-09-24 20:46:14 -06:00
|
|
|
set(TEST_DATA_DIR "${CMAKE_CURRENT_LIST_DIR}/data")
|
2016-08-29 10:12:19 -06:00
|
|
|
|
2014-10-23 14:34:42 -06:00
|
|
|
if (WIN32 AND STATIC)
|
|
|
|
add_definitions(-DSTATICLIB)
|
|
|
|
# miniupnp changed their static define
|
|
|
|
add_definitions(-DMINIUPNP_STATICLIB)
|
|
|
|
endif ()
|
2014-04-09 06:14:35 -06:00
|
|
|
|
2014-10-21 11:27:47 -06:00
|
|
|
find_package(GTest)
|
|
|
|
|
|
|
|
if (GTest_FOUND)
|
|
|
|
include_directories(SYSTEM ${GTEST_INCLUDE_DIRS})
|
|
|
|
else ()
|
2016-08-29 11:56:34 -06:00
|
|
|
message(STATUS "GTest not found on the system: will use GTest bundled with this source")
|
2014-10-21 11:27:47 -06:00
|
|
|
|
2017-02-08 13:38:41 -07:00
|
|
|
include(ExternalProject)
|
|
|
|
ExternalProject_Add(googletest
|
|
|
|
SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/gtest
|
|
|
|
BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/gtest
|
|
|
|
DOWNLOAD_COMMAND ""
|
|
|
|
UPDATE_COMMAND ""
|
|
|
|
INSTALL_COMMAND ""
|
|
|
|
)
|
|
|
|
add_library(gtest UNKNOWN IMPORTED)
|
|
|
|
add_library(gtest_main UNKNOWN IMPORTED)
|
|
|
|
set_target_properties(gtest PROPERTIES
|
2017-02-08 14:34:35 -07:00
|
|
|
IMPORTED_LOCATION "${CMAKE_CURRENT_BINARY_DIR}/gtest/${CMAKE_STATIC_LIBRARY_PREFIX}gtest${CMAKE_STATIC_LIBRARY_SUFFIX}"
|
2017-02-08 13:38:41 -07:00
|
|
|
)
|
|
|
|
set_target_properties(gtest_main PROPERTIES
|
2017-02-08 14:34:35 -07:00
|
|
|
IMPORTED_LOCATION "${CMAKE_CURRENT_BINARY_DIR}/gtest/${CMAKE_STATIC_LIBRARY_PREFIX}gtest_main${CMAKE_STATIC_LIBRARY_SUFFIX}"
|
2017-02-08 13:38:41 -07:00
|
|
|
)
|
|
|
|
add_dependencies(gtest googletest)
|
|
|
|
add_dependencies(gtest_main googletest)
|
2016-08-29 10:12:19 -06:00
|
|
|
|
2017-02-08 13:38:41 -07:00
|
|
|
# Emulate the FindGTest module's variable.
|
|
|
|
set(GTEST_LIBRARIES gtest gtest_main)
|
2019-04-09 11:23:28 -06:00
|
|
|
set(GTEST_BOTH_LIBRARIES gtest gtest_main)
|
2017-02-08 13:38:41 -07:00
|
|
|
include_directories(SYSTEM "${CMAKE_CURRENT_SOURCE_DIR}/gtest/include")
|
|
|
|
endif (GTest_FOUND)
|
2014-03-03 15:07:58 -07:00
|
|
|
|
2017-01-01 18:43:20 -07:00
|
|
|
file(COPY
|
|
|
|
data/wallet_9svHk1.keys
|
|
|
|
data/wallet_9svHk1
|
|
|
|
data/outputs
|
|
|
|
data/unsigned_monero_tx
|
|
|
|
data/signed_monero_tx
|
|
|
|
DESTINATION data)
|
|
|
|
|
2016-08-29 13:37:40 -06:00
|
|
|
add_subdirectory(core_tests)
|
Add fuzz testing using american fuzzy lop
Existing tests: block, transaction, signature, cold outputs,
cold transaction.
Data for these is in tests/data/fuzz.
A convenience shell script is in contrib/fuzz_testing/fuzz.sh, eg:
contrib/fuzz_testing/fuzz.sh signature
The fuzzer will run indefinitely, ^C to stop.
Fuzzing is currently supported for GCC only. I can't get CLANG
to build Monero here as it dies on some system headers, so if
someone wants to make it work on both, that'd be great.
In particular, the __AFL_LOOP construct should be made to work
so that a given run can fuzz multiple inputs, as the C++ load
time is substantial.
2017-06-24 05:38:41 -06:00
|
|
|
add_subdirectory(fuzz)
|
2014-10-21 11:01:56 -06:00
|
|
|
add_subdirectory(crypto)
|
|
|
|
add_subdirectory(functional_tests)
|
|
|
|
add_subdirectory(performance_tests)
|
|
|
|
add_subdirectory(core_proxy)
|
|
|
|
add_subdirectory(unit_tests)
|
|
|
|
add_subdirectory(difficulty)
|
ArticMine's new block weight algorithm
This curbs runaway growth while still allowing substantial
spikes in block weight
Original specification from ArticMine:
here is the scaling proposal
Define: LongTermBlockWeight
Before fork:
LongTermBlockWeight = BlockWeight
At or after fork:
LongTermBlockWeight = min(BlockWeight, 1.4*LongTermEffectiveMedianBlockWeight)
Note: To avoid possible consensus issues over rounding the LongTermBlockWeight for a given block should be calculated to the nearest byte, and stored as a integer in the block itself. The stored LongTermBlockWeight is then used for future calculations of the LongTermEffectiveMedianBlockWeight and not recalculated each time.
Define: LongTermEffectiveMedianBlockWeight
LongTermEffectiveMedianBlockWeight = max(300000, MedianOverPrevious100000Blocks(LongTermBlockWeight))
Change Definition of EffectiveMedianBlockWeight
From (current definition)
EffectiveMedianBlockWeight = max(300000, MedianOverPrevious100Blocks(BlockWeight))
To (proposed definition)
EffectiveMedianBlockWeight = min(max(300000, MedianOverPrevious100Blocks(BlockWeight)), 50*LongTermEffectiveMedianBlockWeight)
Notes:
1) There are no other changes to the existing penalty formula, median calculation, fees etc.
2) There is the requirement to store the LongTermBlockWeight of a block unencrypted in the block itself. This is to avoid possible consensus issues over rounding and also to prevent the calculations from becoming unwieldy as we move away from the fork.
3) When the EffectiveMedianBlockWeight cap is reached it is still possible to mine blocks up to 2x the EffectiveMedianBlockWeight by paying the corresponding penalty.
Note: the long term block weight is stored in the database, but not in the actual block itself,
since it requires recalculating anyway for verification.
2019-01-21 10:18:50 -07:00
|
|
|
add_subdirectory(block_weight)
|
2014-10-21 11:01:56 -06:00
|
|
|
add_subdirectory(hash)
|
|
|
|
add_subdirectory(net_load_tests)
|
2017-11-26 01:25:42 -07:00
|
|
|
if (BUILD_GUI_DEPS)
|
|
|
|
add_subdirectory(libwallet_api_tests)
|
|
|
|
endif()
|
2014-03-03 15:07:58 -07:00
|
|
|
|
2018-11-20 06:40:51 -07:00
|
|
|
if (TREZOR_DEBUG)
|
|
|
|
add_subdirectory(trezor)
|
|
|
|
endif()
|
|
|
|
|
2014-03-03 15:07:58 -07:00
|
|
|
# add_subdirectory(daemon_tests)
|
|
|
|
|
2014-10-21 11:01:56 -06:00
|
|
|
set(hash_targets_sources
|
|
|
|
hash-target.cpp)
|
|
|
|
|
|
|
|
set(hash_targets_headers)
|
2014-03-03 15:07:58 -07:00
|
|
|
|
2014-10-21 11:01:56 -06:00
|
|
|
add_executable(hash-target-tests
|
|
|
|
${hash_targets_sources}
|
|
|
|
${hash_targets_headers})
|
|
|
|
target_link_libraries(hash-target-tests
|
2016-09-17 11:59:29 -06:00
|
|
|
PRIVATE
|
2014-10-21 11:01:56 -06:00
|
|
|
cryptonote_core)
|
|
|
|
set_property(TARGET hash-target-tests
|
|
|
|
PROPERTY
|
2016-08-29 10:12:19 -06:00
|
|
|
FOLDER "${folder}")
|
2014-10-21 11:01:56 -06:00
|
|
|
|
|
|
|
add_test(
|
|
|
|
NAME hash-target
|
|
|
|
COMMAND hash-target-tests)
|
2014-03-03 15:07:58 -07:00
|
|
|
|
2016-08-29 10:17:02 -06:00
|
|
|
set(enabled_tests
|
2017-10-19 09:46:17 -06:00
|
|
|
core_tests
|
2016-08-29 10:17:02 -06:00
|
|
|
difficulty
|
ArticMine's new block weight algorithm
This curbs runaway growth while still allowing substantial
spikes in block weight
Original specification from ArticMine:
here is the scaling proposal
Define: LongTermBlockWeight
Before fork:
LongTermBlockWeight = BlockWeight
At or after fork:
LongTermBlockWeight = min(BlockWeight, 1.4*LongTermEffectiveMedianBlockWeight)
Note: To avoid possible consensus issues over rounding the LongTermBlockWeight for a given block should be calculated to the nearest byte, and stored as a integer in the block itself. The stored LongTermBlockWeight is then used for future calculations of the LongTermEffectiveMedianBlockWeight and not recalculated each time.
Define: LongTermEffectiveMedianBlockWeight
LongTermEffectiveMedianBlockWeight = max(300000, MedianOverPrevious100000Blocks(LongTermBlockWeight))
Change Definition of EffectiveMedianBlockWeight
From (current definition)
EffectiveMedianBlockWeight = max(300000, MedianOverPrevious100Blocks(BlockWeight))
To (proposed definition)
EffectiveMedianBlockWeight = min(max(300000, MedianOverPrevious100Blocks(BlockWeight)), 50*LongTermEffectiveMedianBlockWeight)
Notes:
1) There are no other changes to the existing penalty formula, median calculation, fees etc.
2) There is the requirement to store the LongTermBlockWeight of a block unencrypted in the block itself. This is to avoid possible consensus issues over rounding and also to prevent the calculations from becoming unwieldy as we move away from the fork.
3) When the EffectiveMedianBlockWeight cap is reached it is still possible to mine blocks up to 2x the EffectiveMedianBlockWeight by paying the corresponding penalty.
Note: the long term block weight is stored in the database, but not in the actual block itself,
since it requires recalculating anyway for verification.
2019-01-21 10:18:50 -07:00
|
|
|
block_weight
|
2016-08-29 10:17:02 -06:00
|
|
|
hash
|
|
|
|
performance_tests
|
|
|
|
core_proxy
|
Add fuzz testing using american fuzzy lop
Existing tests: block, transaction, signature, cold outputs,
cold transaction.
Data for these is in tests/data/fuzz.
A convenience shell script is in contrib/fuzz_testing/fuzz.sh, eg:
contrib/fuzz_testing/fuzz.sh signature
The fuzzer will run indefinitely, ^C to stop.
Fuzzing is currently supported for GCC only. I can't get CLANG
to build Monero here as it dies on some system headers, so if
someone wants to make it work on both, that'd be great.
In particular, the __AFL_LOOP construct should be made to work
so that a given run can fuzz multiple inputs, as the C++ load
time is substantial.
2017-06-24 05:38:41 -06:00
|
|
|
fuzz
|
2016-08-29 10:17:02 -06:00
|
|
|
unit_tests)
|
|
|
|
|
|
|
|
add_custom_target(tests DEPENDS enabled_tests)
|
2016-08-29 10:12:19 -06:00
|
|
|
set_property(TARGET tests PROPERTY FOLDER "${folder}")
|