benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
lumiera_/tests/basics/dependency-configuration-test.cpp

396 lines
14 KiB
C++
Raw Normal View History

DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
/*
DependencyConfiguration(Test) - verify configuration for injecting dependencies
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
Copyright (C)
2018, Hermann Vosseler <Ichthyostega@web.de>
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
  **Lumiera** is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the
  Free Software Foundation; either version 2 of the License, or (at your
  option) any later version. See the file COPYING for further details.
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
* *****************************************************************/
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
/** @file dependency-configuration-test.cpp
** unit test \ref DependencyConfiguration_test
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
** @remark this test was written 3/2018 as a byproduct of the third rewrite
** of the framework for singletons and dependency-injection. It is
** quite redundant with the previously existing DependencyFactory_test
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
*/
#include "lib/test/run.hpp"
#include "lib/format-cout.hpp"
#include "lib/test/test-helper.hpp"
#include "lib/util.hpp"
DI: (WIP) switch to totally rewritten new implementation of lib::Depend (#1086) - state-of-the-art implementation of access with Double Checked Locking + Atomics - improved design for configuration of dependencies. Now at the provider, not the consumer - support for exposing services with a lifecycle through the lib::Depend<SRV> front-end
2018-03-30 18:46:13 +02:00
#include "lib/depend.hpp"
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
#include "lib/depend-inject.hpp"
namespace lib {
namespace test{
using ::Test;
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
using util::isSameObject;
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
namespace {
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
struct Dum
Library: replace boost::noncopyable by our own library solution Benefits - get rid of yet another pervasive Boost dependency - define additional more fine grained policies (move only, clonable)
2018-03-24 05:35:13 +01:00
: util::NonCopyable
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
{
virtual ~Dum() { }
virtual int probe() =0;
};
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
int checksum = 0;
template<int N>
struct Dummy
: Dum
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
{
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
Dummy() { checksum += N; }
~Dummy() { checksum -= N; }
virtual int
probe() override
{
return N * checksum;
}
};
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
}
Library: uniform definition scheme for error-IDs In the Lumiera code base, we use C-String constants as unique error-IDs. Basically this allows to create new unique error IDs anywhere in the code. However, definition of such IDs in arbitrary namespaces tends to create slight confusion and ambiguities, while maintaining the proper use statements requires some manual work. Thus I introduce a new **standard scheme** * Error-IDs for widespread use shall be defined _exclusively_ into `namespace lumiera::error` * The shorthand-Macro `LERR_()` can now be used to simplify inclusion and referral * (for local or single-usage errors, a local or even hidden definition is OK)
2024-03-16 02:04:47 +01:00
using LERR_(LIFECYCLE);
using LERR_(FATAL);
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
/***************************************************************************//**
* @test verify the various modes of creating dependencies.
* - standard case is singleton creation
* - configuration of a specific subclass for the singleton
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
* - expose a service with explicit lifecycle
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
* - use of a custom factory function
* - injection of a mock implementation for unit tests
*
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
* @remark this test basically covers the same ground as DependencyFactory_test;
* but while the latter exists since our second rewrite of lib::Depend (2013),
* this test here is a byproduct of the third rewrite from 2018 and focuses
* more on the configuration and instance identities.
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
* @see lib::Dependency
* @see Singleton_test
*/
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
class DependencyConfiguration_test
: public Test
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
{
virtual void
run (Arg)
{
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
checksum = 0;
verify_Singleton();
verify_SubclassSingleton();
verify_expose_Service_with_Lifecycle();
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
verify_automaticReplacement();
DI: implement creating singleton from arbitrary (user provided) closure/functor/lambda this is quite an ugly feature, but I couldn't come up with any convincing argument *not* to implement it (and its low hanging fruit)
2018-03-22 06:53:56 +01:00
verify_customFactory();
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
DI: implement creating singleton from arbitrary (user provided) closure/functor/lambda this is quite an ugly feature, but I couldn't come up with any convincing argument *not* to implement it (and its low hanging fruit)
2018-03-22 06:53:56 +01:00
CHECK (9+7+5+1 == checksum); // singletons stay alive until application shutdown
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
}
/** @test without special configuration, singletons are injected as dependency */
void
verify_Singleton()
{
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
Depend<Dummy<1>> dep11;
Depend<Dummy<5>> dep5;
Depend<Dummy<1>> dep12;
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
CHECK (1 == sizeof(dep11));
CHECK (1 == sizeof(dep12));
CHECK (1 == sizeof(dep5));
// no singleton instance created yet
CHECK ( 0 == checksum );
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
CHECK ( 1*1 == dep11().probe() );
CHECK ( 1 == checksum );
CHECK ((1+5)*5 == dep5().probe() );
CHECK ((1+5) == checksum );
CHECK ((1+5)*1 == dep12().probe() );
CHECK ((1+5) == checksum );
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
CHECK (not isSameObject (dep11, dep12));
CHECK ( isSameObject (dep11(), dep12()));
}
/** @test preconfigure a specific subclass to be injected as singleton dependency */
void
verify_SubclassSingleton()
{
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
// unable to create singleton instance of abstract baseclass
VERIFY_ERROR (FATAL, Depend<Dum>{}() );
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
CHECK ((1+5) == checksum );
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
Depend<Dum> dumm;
DependInject<Dum>::useSingleton<Dummy<7>>();
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
CHECK ((1+5) == checksum );
CHECK ((1+5+7)*7 == dumm().probe() );
CHECK ((1+5+7) == checksum );
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
VERIFY_ERROR (LIFECYCLE, DependInject<Dum>::useSingleton<Dummy<9>>() );
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
CHECK ((1+5+7)*7 == Depend<Dum>{}().probe() );
CHECK ((1+5+7)*7 == dumm().probe() );
CHECK ((1+5+7) == checksum );
}
/** @test expose a dedicated service instance, which can be shut down */
void
verify_expose_Service_with_Lifecycle()
{
CHECK ((1+5+7) == checksum );
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
struct SubDummy
: Dummy<3>
{
virtual int
probe() override
{
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
return offset - checksum;
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
}
int offset = 0;
};
Depend<Dummy<3>> dep3;
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
CHECK ((1+5+7) == checksum );
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
{
DependInject<Dummy<3>>::ServiceInstance<SubDummy> service{};
CHECK (service);
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
CHECK ((1+5+7+3) == checksum );
CHECK (-(1+5+7+3) == dep3().probe() );
CHECK ((1+5+7+3) == checksum );
service->offset = (1+5+7);
CHECK ( -3 == dep3().probe() );
CHECK ((1+5+7+3) == checksum );
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
}
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
CHECK ((1+5+7) == checksum );
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
VERIFY_ERROR (LIFECYCLE, dep3().probe() );
VERIFY_ERROR (LIFECYCLE, DependInject<Dum>::ServiceInstance<SubDummy>{} );
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
CHECK ((1+5+7) == checksum );
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
}
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
/** @test injecting test mocks temporarily */
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
void
verify_automaticReplacement()
{
DI: clean-up and document the TDD test ...written as byproduct from the reimplementation draft. NOTE there is a quite similar test from 2013, DependencyFactory_test For now I prefer to retain both, since the old one should just continue to work with minor API adjustments (and thus prove this rewrite is a drop-in replacement). On the long run those two tests could be merged eventually...
2018-03-19 05:27:37 +01:00
Depend<Dum> dumm;
Depend<Dummy<3>> depp;
CHECK ((1+5+7) == checksum );
CHECK ((1+5+7)*7 == dumm().probe() );
VERIFY_ERROR (LIFECYCLE, depp().probe() );
struct Mock
: Dummy<3>
{
virtual int
probe() override
{
return response;
}
int response = -1;
};
{////////////////////////////////////////////////////TEST-Scope
DependInject<Dum>::Local<Mock> mockDumm;
DependInject<Dummy<3>>::Local<Mock> mockDummy3;
CHECK ((1+5+7) == checksum );
CHECK (!mockDumm);
CHECK (!mockDummy3);
CHECK (-1 == dumm().probe() ); // NOTE: now returning the response from the mock instance
CHECK ( mockDumm);
CHECK (!mockDummy3);
CHECK ((1+5+7+3) == checksum );
CHECK (-1 == mockDumm->probe() );
CHECK ((1+5+7+3) == checksum );
mockDumm->response = 11;
CHECK (11 == dumm().probe() ); // NOTE: now returning the response changed on the mock instance
CHECK (!mockDummy3); // the second mock is still in not yet created state...
CHECK ((1+5+7+3) == checksum );
CHECK (-1 == depp().probe() );
CHECK ((1+5+7+3+3) == checksum ); // ...and now we got a second mock instance!
CHECK ( mockDummy3);
CHECK (-1 == mockDummy3->probe() );
CHECK ((1+5+7+3+3) == checksum );
mockDummy3->response = 22;
CHECK (22 == depp().probe() );
mockDumm->response = 12;
CHECK (22 == depp().probe() ); // these are really two distinct instances
CHECK (12 == dumm().probe() );
CHECK ((1+5+7+3+3) == checksum );
}////////////////////////////////////////////////////(End)TEST-Scope
// Back to normal: the Mocks are gone, original behaviour uncovered
CHECK ((1+5+7) == checksum );
CHECK ((1+5+7)*7 == dumm().probe() );
VERIFY_ERROR (LIFECYCLE, depp().probe() );
CHECK ((1+5+7) == checksum );
{/////////////////////////////////////////////////////////Service-Scope
DependInject<Dummy<3>>::ServiceInstance<Mock> service{};
CHECK ((1+5+7+3) == checksum ); // NOTE: we got a new Dummy<3> service instance
CHECK (-1 == depp().probe() ); // ..... which returns the pristine mock response
service->response = 33;
CHECK (33 == depp().probe() );
CHECK ((1+5+7+3) == checksum );
{/////////////////////////////////////////////////////////NESTED-TEST-Scope
DependInject<Dummy<3>>::Local<Mock> mockDummy31;
CHECK (!mockDummy31);
CHECK ((1+5+7+3) == checksum ); // ...while SerivceInstance is created eagerly
CHECK (-1 == depp().probe() ); // the Local mock instance is only created on-demand
CHECK ((1+5+7+3+3) == checksum );
mockDummy31->response = 44;
CHECK (44 == depp().probe() );
CHECK (44 == mockDummy31->probe() );
CHECK (33 == service->probe() );
CHECK (mockDummy31->response != service->response);
service->response = 34;
CHECK (44 == depp().probe() ); // NOTE: remains shadowed by the mockDummy
CHECK (44 == mockDummy31->probe() );
CHECK (34 == service->probe() );
CHECK ((1+5+7+3+3) == checksum );
}/////////////////////////////////////////////////////////(End)NESTED-TEST-Scope
// Now the mock is gone and the service instance becomes uncovered
CHECK ((1+5+7+3) == checksum );
CHECK (34 == depp().probe() ); // now reveals the response changed from within the nested test scope
CHECK ((1+5+7+3) == checksum );
}/////////////////////////////////////////////////////////(End)Service-Scope
// Back to normal: Mocks is gone, Service is shutdown, original behaviour uncovered
CHECK ((1+5+7) == checksum );
VERIFY_ERROR (LIFECYCLE, depp().probe() );
CHECK ((1+5+7)*7 == dumm().probe() );
CHECK ((1+5+7) == checksum );
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
}
DI: implement creating singleton from arbitrary (user provided) closure/functor/lambda this is quite an ugly feature, but I couldn't come up with any convincing argument *not* to implement it (and its low hanging fruit)
2018-03-22 06:53:56 +01:00
DOC: some doxygen fixes
2018-09-05 04:48:11 +02:00
/** @test instance creation can be preconfigured with a closure.
DI: implement creating singleton from arbitrary (user provided) closure/functor/lambda this is quite an ugly feature, but I couldn't come up with any convincing argument *not* to implement it (and its low hanging fruit)
2018-03-22 06:53:56 +01:00
* Both Singleton and Test-Mock creation can optionally be performed through a
* user provided Lambda or Functor. To demonstrate this, we use a `Veryspecial` local class,
* which takes an `int&` as constructor parameter -- and we create the actual instance through
* a lambda, which happens to capture a local variable by reference.
* @warning this can be dangerous; in the example demonstrated here, the created singleton instance
* continues to live until termination of the test-suite. After leaving this test function,
* it thus holds a dangling reference, pointing into stack memory....
*/
void
verify_customFactory()
{
CHECK ((1+5+7) == checksum );
struct Veryspecial
: Dummy<9>
{
Veryspecial(int& ref)
: magic_{ref}
{ }
int& magic_;
virtual int
probe() override
{
return magic_++;
}
};
DI: special solution for singletons with private default ctor ...which declare DependencyFactory as friend. Yes, we want to encourrage that usage pattern. Problem is, std::is_constructible<X> gives a misleading result in that case. We need to do the instantiation check within the scope of DependencyFactory
2018-03-30 06:48:34 +02:00
// NOTE: the following is rejected due to missing default ctor
DependInject<Dummy<9>>::useSingleton<Veryspecial>();
VERIFY_ERROR (FATAL, Depend<Dummy<9>>{}() );
DI: implement creating singleton from arbitrary (user provided) closure/functor/lambda this is quite an ugly feature, but I couldn't come up with any convincing argument *not* to implement it (and its low hanging fruit)
2018-03-22 06:53:56 +01:00
int backdoor = 22;
DependInject<Dummy<9>>::useSingleton ([&]{ return new Veryspecial{backdoor}; });
CHECK ((1+5+7) == checksum );
CHECK ( 22 == backdoor );
Depend<Dummy<9>> tricky;
CHECK ((1+5+7) == checksum );
CHECK (22 == backdoor );
CHECK (22 == tricky().probe());
CHECK (23 == backdoor );
CHECK ((1+5+7+9) == checksum ); // Veryspecial Dummy<9> subclass was created on the heap
// and will continue to live there until the testsuite terminates
backdoor = 41;
CHECK (41 == tricky().probe());
CHECK (42 == backdoor );
Depend<Dum> dumm;
CHECK ((1+5+7+9)*7 == dumm().probe() );
{////////////////////////////////////////////////////TEST-Scope
DI: special solution for singletons with private default ctor ...which declare DependencyFactory as friend. Yes, we want to encourrage that usage pattern. Problem is, std::is_constructible<X> gives a misleading result in that case. We need to do the instantiation check within the scope of DependencyFactory
2018-03-30 06:48:34 +02:00
////////////// NOTE: the following does not compile
// // since Veryspecial has no default ctor...
// //
// DependInject<Dum>::Local<Dum> impossible;
DI: implement creating singleton from arbitrary (user provided) closure/functor/lambda this is quite an ugly feature, but I couldn't come up with any convincing argument *not* to implement it (and its low hanging fruit)
2018-03-22 06:53:56 +01:00
DependInject<Dum>::Local<Dum> insidious ([&]{ return new Veryspecial{backdoor}; });
CHECK ((1+5+7+9) == checksum );
CHECK (not insidious);
CHECK (42 == dumm().probe() );
CHECK (43 == backdoor );
CHECK ((1+5+7+9+9) == checksum );
CHECK (isSameObject (dumm(), *insidious));
CHECK (43 == tricky().probe());
CHECK (44 == backdoor );
backdoor = -1;
CHECK (-1 == dumm().probe() );
CHECK ( 0 == backdoor );
CHECK ((1+5+7+9+9) == checksum );
}////////////////////////////////////////////////////(End)TEST-Scope
DI: special solution for singletons with private default ctor ...which declare DependencyFactory as friend. Yes, we want to encourrage that usage pattern. Problem is, std::is_constructible<X> gives a misleading result in that case. We need to do the instantiation check within the scope of DependencyFactory
2018-03-30 06:48:34 +02:00
DI: implement creating singleton from arbitrary (user provided) closure/functor/lambda this is quite an ugly feature, but I couldn't come up with any convincing argument *not* to implement it (and its low hanging fruit)
2018-03-22 06:53:56 +01:00
CHECK ((1+5+7+9) == checksum );
CHECK ((1+5+7+9)*7 == dumm().probe() );
CHECK ( 0 == tricky().probe());
CHECK (+1 == backdoor );
} // NOTE: Veryspecial holds a dangling reference into stack memory from now on!
DI: extract testcode into new unit test
2018-03-19 03:30:22 +01:00
};
LAUNCHER (DependencyConfiguration_test, "unit common");
}} // namespace lib::test
Reference in a new issue Copy permalink