Sophie

Sophie

distrib > Mandriva > 2010.2 > i586 > media > contrib-release-src > by-pkgid > 59f06e59def7bbfb45949227d7e93ae8 > files > 2

perl-DBD-Mock-1.390.0-1mdv2010.0.src.rpm

%define upstream_name    DBD-Mock
%define upstream_version 1.39

Name:       perl-%{upstream_name}
Version:    %perl_convert_version %{upstream_version}
Release:    %mkrel 1

Summary:    Mock database driver for testing
License:    GPL+ or Artistic
Group:      Development/Perl
Url:        http://search.cpan.org/dist/%{upstream_name}
Source0:    http://www.cpan.org/modules/by-module/DBD/%{upstream_name}-%{upstream_version}.tar.gz

BuildRequires: perl(DBI)
BuildRequires: perl(Test::More)
BuildRequires: perl(Module::Build::Compat)
BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}

%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 the
DBD::Pg manpage or the DBD::mysql manpage) 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 the DBD::AnyData
manpage or the DBD::SQLite manpage 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 the
Test::MockObject manpage to create a fully dynamic handle. There is an
excellent article by chromatic about using the Test::MockObject manpage in
this and other ways, strongly recommended. (See the SEE ALSO manpage for a
link)

%prep
%setup -q -n %{upstream_name}-%{upstream_version}

%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
%make

%check
make test

%install
rm -rf %buildroot
%makeinstall_std

%clean
rm -rf %buildroot

%files
%defattr(-,root,root)
%doc Changes README
%{_mandir}/man3/*
%perl_vendorlib/DBD


%changelog
* Wed Jul 29 2009 Jérôme Quelin <jquelin@mandriva.org> 1.390.0-1mdv2010.0
+ Revision: 403092
- rebuild using %%perl_convert_version

* Wed Nov 26 2008 Guillaume Rousse <guillomovitch@mandriva.org> 1.39-1mdv2009.1
+ Revision: 307032
- import perl-DBD-Mock


* Wed Nov 26 2008 cpan2dist 1.39-1mdv
- initial mdv release, generated with cpan2dist