-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Reuben,
thanks for your answer. I practise testing models and controllers
(preferably models) since about 2 months and by now I get some routine.
But libs are a new one. I will see how these things work out!
Anja
Am 25.10.2013 15:08, schrieb Reuben Helms:
> 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
> <c...@anjaliebermann.de>wrote:
>
> Hi Reuben,
>
> 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,
>>>>
>>>> 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
>>>>>
>>>>
>
>>
>> --
>> 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+unsubscr...@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.
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlJtT2EACgkQbOdiIJzHNKEA5wCghrKlF+a5LBxou0Pefvbi79D9
1/cAn2nbNhU8EWZSvIZjtAMPzHjqmthF
=reiU
-----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 the Google Groups
"CakePHP" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to cake-php+unsubscr...@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.
