My experience with unit testing in CakePHP is minimal. However, I do believe it should be possible.
CakePHP has nice classes for assisting with testing the specific cases of Controllers (ControllerTestCase) and creating fixtures (CakeTestFixture) for using with model testing.
They also provide the CakeTestCase, which is an extension of the PHPUnitTestCase (or whatever the proper PHPUnit test case class is called). I believe you should be able to use this, just as you would if you were writing tests for a model, or a helper, or a utility. In fact, I would draw your attention to any of the test cases in Cake/Test/Case/Utility. All of these tests operate on classes that operate similar to libraries. Some are fully static, some require instances of classes.
The moment of truth for your Lib classes will be when it comes to mocking objects that your Lib classes use. Things like Dependency Injection are going to be important, so you can feed your Lib classes a mocked object or mocked model in the tests and still have it operate well in the runtime environment. For this, I would recommend looking at existing tests in the CakePHP installation, especially examples like behaviours and components and helpers, that rely, in part, in external objects, but have those mocked so you can control input, and accurately place asserts on the output from your Libs.
Regards
Reuben Helms
On Fri, Oct 25, 2013 at 8:50 PM, Anja Liebermann <cake@anjaliebermann.de> wrote:
-----BEGIN PGP SIGNED MESSAGE-----Hi Reuben,
Hash: SHA1
for the moment I opted for putting the code into a lib.
So now the next question. How can I wirte tests for it? Can I do that
within the CakePHP testframework? If yes, how do I call it? Is there an
example anywhere?
Or do I have to call phpunit test from the bash?
Any hint helping me to be a good developer girl keeping the promise to
always write tests woulod be appreciated!
Anja
Am 15.10.2013 09:28, schrieb Reuben:
> I can't say what is best practice, but here are things that I've done in
> the past.
>
> Putting in a component:
> For a little bit, I was shoving things that did not need to be directly in
> the Model, into a component. This is great, as long as you only need to
> access that logic from a Controller. However, if the existing logic is
> already in a Model, and you want to move it out, then I would not suggest
> the component. For me, the Component is about subtlely changing the
> behavior of the controller, making use of startUp, shutdownDown and the
> lifecycle flow. If the logic doesn't have anything to do with lifecycle of
> the controller, then I wouldn't bother putting it in the component.
>
> Putting in a lib:
> My next pattern was putting functionality into a Lib/* directory. I was
> particularly fond of doing this for SOAP Web Services. The controller
> would still call a model, but then the model would call the Web Service to
> perform SOAP call. The advantage was that these Web Service libraries
> would be available from controllers and components as well.
>
> My 2 cents. Go nuts with the structure if your app.
>
> If you have an obese model that is filled with helper functions that don't
> directly need services provided by the model, don't be afraid to add
> structure that suites you. I would create a ModelHelper directory, and
> then create model helper classes that the model would call as required.
>
> i.e.
>
> Model/MyObeseModel.php
> ModelHelper/MyObeseModelHelper.php
>
> and in MyObeseModel.php
>
> App::uses('MyObeseModelHelper', 'ModelHelper');
>
> Then you can create a new instance of MyObeseModelHelper as you need it, or
> instantiate it in the constructor, so it's always available. If they're
> really helper methods, you might get away with having them be static, and
> pass the model in.
>
> At least by using ModelHelper, you avoid a Lib directory that could get
> filled with all sorts of cruft, and know that ModelHelper contains helpers
> for models. You could go one step further have have
> Model\Helper\MyObeseModelHelper.php. I think that might be possible with
> CakePHP 2.x and the App::uses() clause, and would probably do rather well
> in CakePHP 3.0, when we can start using namespaces properly.
>
> This might not be the best way, but it's a way, and I'd also love to hear
> if anyone else has a recommendation or two.
>
> Regards
> Reuben Helms
>
> On Sunday, 13 October 2013 23:49:14 UTC+10, acl68 wrote:
>>
> Hello everybody,iEYEARECAAYFAlJqTQcACgkQbOdiIJzHNKHhIACdHDb4vYabnmMv/IKP019dq0HF
>
> I have a slightly advanced question.
> I just build an app which at some point goes through a lot of evaluation
> methods to find a certain value in a heap of values.
>
> I want to follow the fat model theory also because it makes methods
> easier for unit tests.
>
> Now my model shows a tendency to not only become fat, but obese and I
> consider putting the advanced logic in another place. The question is:
> What could that be?
>
> Normally I would create models which would extend my obese model and
> place the methods there so they are out of the way. But most of these
> methods don't need direct dealing with the database so I could just put
> them elsewhere shuffle data in and get the output out after they went
> though this "black evaluation box".
>
> Would a component be this place? Or a model without db table?
> What would be the professional CakePHP way of doing this?
>
> Thanky for any hints in advance as always!
>
>
> Anja
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
3tUAn2w9fGXfelAponcoOYRFSFNRmgFX
=KHrs
-----END PGP SIGNATURE-----
--
Like Us on FaceBook https://www.facebook.com/CakePHP
Find us on Twitter http://twitter.com/CakePHP
---
You received this message because you are subscribed to a topic in the Google Groups "CakePHP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cake-php/lQkvS37N9rg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cake-php+unsubscribe@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/groups/opt_out.
Like Us on FaceBook https://www.facebook.com/CakePHP
Find us on Twitter http://twitter.com/CakePHP
---
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cake-php+unsubscribe@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment