File perl-DBD-Mock.spec of Package perl-DBD-Mock

Overview Repositories Revisions Requests Users Attributes Meta

File perl-DBD-Mock.spec of Package perl-DBD-Mock

#
# spec file for package perl-DBD-Mock
#
# Copyright (c) 2021 SUSE LLC
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.

# Please submit bugfixes or comments via https://bugs.opensuse.org/
#

%define cpan_name DBD-Mock
Name:           perl-DBD-Mock
Version:        1.59
Release:        0
Summary:        Mock database driver for testing
License:        Artistic-1.0 OR GPL-1.0-or-later
URL:            https://metacpan.org/release/%{cpan_name}
Source0:        https://cpan.metacpan.org/authors/id/J/JL/JLCOOPER/%{cpan_name}-%{version}.tar.gz
Source1:        cpanspec.yml
BuildArch:      noarch
BuildRequires:  perl
BuildRequires:  perl-macros
BuildRequires:  perl(DBI) >= 1.3
BuildRequires:  perl(List::Util) >= 1.27
BuildRequires:  perl(Module::Build::Tiny) >= 0.035
BuildRequires:  perl(Test::Exception) >= 0.310000
Requires:       perl(DBI) >= 1.3
Requires:       perl(List::Util) >= 1.27
%{perl_requires}

%description
Testing with databases can be tricky. If you are developing a system
married to a single database then you can make some assumptions about your
environment and ask the user to provide relevant connection information.
But if you need to test a framework that uses DBI, particularly a framework
that uses different types of persistence schemes, then it may be more
useful to simply verify what the framework is trying to do -- ensure the
right SQL is generated and that the correct parameters are bound.
'DBD::Mock' makes it easy to just modify your configuration (presumably
held outside your code) and just use it instead of 'DBD::Foo' (like DBD::Pg
or DBD::mysql) in your framework.

There is no distinct area where using this module makes sense. (Some people
may successfully argue that this is a solution looking for a problem...)
Indeed, if you can assume your users have something like DBD::AnyData or
DBD::SQLite or if you do not mind creating a dependency on them then it
makes far more sense to use these legitimate driver implementations and
test your application in the real world -- at least as much of the real
world as you can create in your tests...

And if your database handle exists as a package variable or something else
easily replaced at test-time then it may make more sense to use
Test::MockObject to create a fully dynamic handle. There is an excellent
article by chromatic about using Test::MockObject in this and other ways,
strongly recommended. (See SEE ALSO for a link)

%prep
%autosetup  -n %{cpan_name}-%{version}
find . -type f ! -path "*/t/*" ! -name "*.pl" ! -path "*/bin/*" ! -path "*/script/*" ! -name "configure" -print0 | xargs -0 chmod 644

%build
perl Build.PL --installdirs=vendor
./Build build --flags=%{?_smp_mflags}

%check
./Build test

%install
./Build install --destdir=%{buildroot} --create_packlist=0
%perl_gen_filelist

%files -f %{name}.files
%doc Changes CONTRIBUTING.md minil.toml README.md
%license LICENSE

%changelog

Places

File perl-DBD-Mock.spec of Package perl-DBD-Mock

Places