Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

develop / inflector_helper.php - camelize() fail #1151

Closed
tiyowan opened this Issue · 11 comments

4 participants

@tiyowan

commit 1e6b72c

breaks camelize()

Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-thisIsTheString
+hisIsTheString
@philsturgeon

Fixed this which can be seen in the latest build:

http://travis-ci.org/#!/EllisLab/CodeIgniter/builds/833572

@toopay

:+1:
It looks like from this point, we have a functional integrated unit testing.

@tiyowan

@toopay Yes indeed. :)

@philsturgeon

Let's not get ahead of ourselves too much. It used to be functional before we changed some 3.0 stuff. Now, its obviously good 3.0 is working again, but there are quite a few tests specifically marked as incomplete, or just not written.

@toopay can you take a look at those marked as incomplete? After that it's just Database - which is a big job which will probably be a combined effort - and I'll merge this to develop.

@toopay

Sure.

For database testing, i think we will need to dump out a database schema and entries, then test the query builder API against those schema in several environments (which supported by travis). If this test scenario approved, i could easily ported my Gas ORM test scenario into our query builder test case. Or do you have other plan for that? cc : @pkriete

@tiyowan

@philsturgeon @toopay The tests we have currently are still a long way from providing good code coverage. Also, for some of the more complex libraries, such as form_validation.php, you will need to maintain a slightly modified version that uses dependency injection to take care of the CI singleton. I'm working on it atm. How do you propose merging that structure into develop?

@philsturgeon

@tiyowan I know, thats why I said "let's not get ahead of ourselves". We currently have our existing unit tests working, but we have a lot more to get done.

We are a bit screwed for dependency injection, but we COULD build a MY_Form_validaiton on the fly for testing, which wouldn't be the nicest solution but would work.

Either way, when I say "Merge into develop" I don't mean "Unit Tests are ready to go live" I mean "they are a good enough base for everyone to start contributing too" which is not far from where we are now.

@tiyowan

@philsturgeon All right. Let's see where I can go with form_validation.php. What I have now works with dependency injection, but I need more time to understand how the helpers are loaded in, since form_validation autoloads form_helper in its constructor. As of two hours ago, I managed to write a min_length() test that passes, but I still have to crack autoloading helpers. As always, thank you for your time.

@toopay

Guys. At this post there are a common understanding from CI community that the current unit-test branch is NOT WORKING, thats why i'm glad and said that we now have a functional (mean, it simply works!) unit testing. Is this something that we could not celebrate? :)

And like i said in those post, current CI architecture did not allow smooth integration. Its hard, to create a stub or mocking object, with the whole singleton pattern everywhere. The DB package was the only part, which at least, easier than other component, to be tested, from my experience in Gas ORM.

If we're gonna implement DI all over the place, aside from the fact that this is basically a drastic re-written of this framework, there are also some cons. Mostly, it will drastically effect the performance, since all object will need to instantiate everytime we "inject" the depedency into some component. Whether this DI change would apply into all core components? I dont think this could be done, easily, without any debate (and flamewar, within community).

So what i propose for now, is to separate things. For example, in 'form_validation.php' we could easily separate it into two class, one is Validator class as an adhoc generic validation class, and the Form_validation will extend that class. This way we could isolate Validator as a component, to be tested, and for Form_validation we could force phpunit to
run with backup-globals enabled (so this will always be the instance of the currently running test class) and will most
likely be an output test for some POST request, alongside with other bootstrap test(like Codeigniter.php test, etc). Other component(s), seems could be tested in relative isolation easily, without the need of separating them into more specific class(es).

@tiyowan

@toopay @philsturgeon This is a basic example using DI for form_validation,php: tiyowan@57fb3e9

Build Status

[Re. celebrating, I'm glad of any change, no matter how small, that improves the current situation]

Could you elaborate further on how to separate and deal with that singleton pattern? Maybe some links to some reading materials. That'd be really helpful.

@toopay

This one, #1161, fixing the skipped and incomplete.

@narfbg narfbg closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.