Welcome Guest, Not a member yet? Register   Sign In
Unit Testing
#1

Hi guys,

I have been using CI for a while but have never felt the need to run unit tests - until now.

What unit testing tool do you use?

I have looked at PhpUnit but accessing private methods is a bit cumbersome.

Is there a CI unit test type module that is worth it's weight?


Many thanks in advance.
Reply
#2

First off, in general you shouldn't test your private methods. That makes the tests too fragile. They're tested through the public API only. And PHPUnit is probably your best solution. CodeCeption is nice, too, but it's based on phpUnit...

This suite by forum member Kenjis is pretty nice. He's even got a pretty good book to go along with it. Tells all you need to know about testing and CI.
Reply
#3

I use Codeception. Codeception is built on top PHPUnit so you can get the best of both worlds. Very easy to integrate acceptance and unit tests. There is a module for codeigniter to work with codeceptions functional testing, but it requires php runkit and I haven't gotten around to trying that out yet.
Codeigniter is simply one of the tools you need to learn to be a successful developer. Always add more tools to your coding arsenal!
Reply
#4

(03-14-2016, 07:25 PM)kilishan Wrote: First off, in general you shouldn't test your private methods. That makes the tests too fragile. They're tested through the public API only. And PHPUnit is probably your best solution. CodeCeption is nice, too, but it's based on phpUnit...

This suite by forum member Kenjis is pretty nice. He's even got a pretty good book to go along with it. Tells all you need to know about testing and CI.

Brilliant - thank you! Kenji's suite is exactly what I'm looking for.

Many thanks.
Reply
#5

@acsv
As kilishan said, you should not test private methods in general.
Tests like that may prevent from refactoring the class under test.

But if you have to do, ci-phpunit-test provide helper method:
See https://github.com/kenjis/ci-phpunit-tes...obj-method
Reply
#6

(03-14-2016, 07:25 PM)kilishan Wrote: First off, in general you shouldn't test your private methods.

It's ok not to test private methods, but that doesn't mean you should be actively discouraged from doing it.
Reply
#7

(03-15-2016, 06:24 AM)Narf Wrote:
(03-14-2016, 07:25 PM)kilishan Wrote: First off, in general you shouldn't test your private methods.

It's ok not to test private methods, but that doesn't mean you should be actively discouraged from doing it.

I'll have to respectfully disagree here. The primary point of testing is to ensure that things work as expected. The secondary point is to ensure that you can make changes to classes without breaking functionality. By limiting your testing the public API of the class, you allow yourself to easily refactor without breaking a bunch of tests that rely on private methods.

I did say, "In general", though, since there are occasions where a private method needs to be tested in isolation due to complexity, etc. The private methods will be tested as the public methods are tested, though.
Reply
#8

(03-15-2016, 06:46 AM)kilishan Wrote:
(03-15-2016, 06:24 AM)Narf Wrote:
(03-14-2016, 07:25 PM)kilishan Wrote: First off, in general you shouldn't test your private methods.

It's ok not to test private methods, but that doesn't mean you should be actively discouraged from doing it.

I'll have to respectfully disagree here. The primary point of testing is to ensure that things work as expected. The secondary point is to ensure that you can make changes to classes without breaking functionality. By limiting your testing the public API of the class, you allow yourself to easily refactor without breaking a bunch of tests that rely on private methods.

I did say, "In general", though, since there are occasions where a private method needs to be tested in isolation due to complexity, etc. The private methods will be tested as the public methods are tested, though.

And a primary goal of unit testing is pinpointing the exact unit of code that isn't functioning properly.

Yes, it makes for harder to maintain tests and yes - in most cases (relatively simple applications) testing only public APIs is completely sufficient. But that doesn't mean the opposite is evil.

You're advocating black-box testing and equating it with all of testing, which is not correct. Smile
Reply
#9

(This post was last modified: 03-15-2016, 10:29 AM by kilishan. Edit Reason: Showing reasoning )

(03-15-2016, 07:29 AM)Narf Wrote: And a primary goal of unit testing is pinpointing the exact unit of code that isn't functioning properly.

Yes, it makes for harder to maintain tests and yes - in most cases (relatively simple applications) testing only public APIs is completely sufficient. But that doesn't mean the opposite is evil.

You're advocating black-box testing and equating it with all of testing, which is not correct. Smile

Didn't mean to imply was evil and even said was to be avoided in general, but that there were cases.

Either way, it's my current advice base on current knowledge and past experiences. Everyone is free to take it or leave it. Smile

EDIT: Since there are debates about this kind of thing all over the internet, and I have zero desire to get caught up in one of those here, I'll just present my thoughts and understanding of the matter in case it helps someone out. If it doesn't, or goes against the way you like to use it and/or think about, that's cool, tool.

I think the biggest issue here is the term, unit. That seems to be where a lot of the differences in opinion come from. When talking about unit testing, you have to decide what unit you're concerned with testing. This could be the entire class, since, if well implemented, it's a unit on it's own, like a blog post, or a URL. Most of the time, for me, that is the unit that I'm concerned about. The public API, or the methods that other classes will be interacting with, are what's important, so that's what I test against. As stated earlier, this makes it easy to refactor what happens behind the public API and having your tests help confirm things are still working as desired.

Other times, the unit that you might be concerned with is a specific method, and this might be private. That's also perfectly valid, and I do feel both uses work together and complement each other. One example on a recent project were some methods that were used for normalizing data for a UK-based company. It was very important to ensure that each of those normalization routines (phone, postal code, etc), worked correctly on their own. So we tested those private methods extensively.

Different people, teams, and projects have different needs and/or ways of thinking about it. As far as I'm concerned, they're often all correct for that situation. So - use what makes sense to you, as long as you've thought it through and have reasons for it.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB