Web Development

Archive for the ‘PHP’ Category

[Last night Nirav and I were discussing about closures and their implementation. I and Nirav often discuss tech. and I’ve been thinking since long to record those discussions. This is the beginning.]

(19:27:32) me: arre.. mereko closure samajh me aagaya.. [I understood closures]
(19:27:37) nirav: wah [gr8!] [my frnd. is always encouraging]
(19:27:44) nirav: isn’t that easy?
(19:27:53) nirav: and interesting at times?
(19:27:53) me: I read closure support in javascript
(19:27:56) nirav: yeah
(19:28:01) nirav: ECMA wala[one defined in ECMA?]
(19:28:03) me: yeah..
(19:28:38) me: to answer ur question.. PHP does’t have native support for closures.. ppl uses clumsy ways to emulate them.. which I don’t think are practicable..
(19:29:15) nirav: and how do they do it?
(19:29:16) me: may be because u can’t return a reference to a function in php..
(19:29:38) nirav: well i don’t need to return reference strictly
(19:29:43) me: they create objects for ‘closure’..
(19:29:46) nirav: i can use indirection using returning type
(19:29:59) me: didn’t get that..
(19:30:05) nirav: yeah, that’s how it is done in java as well
(19:30:06) nirav: i mean
(19:30:12) nirav: e.g.
(19:30:31) nirav: f * function(){}
(19:30:41) nirav: this function is returning function pointer to some closure
(19:30:48) nirav: or block of statement
(19:30:50) nirav: ok
(19:30:51) nirav: ?
(19:30:54) me: yeah,,
(19:30:56) nirav: now
(19:31:07) nirav: instead of returning raw pointer f*
(19:31:29) nirav: i can return a type say t => class t{ void f();}
(19:31:42) nirav: so that client of the method can get t and invoke f
(19:31:57) nirav: its indirect so ugly way of using ‘closure’
(19:32:05) me: hmm…
(19:32:10) nirav: samja? [understood?]
(19:32:14) me: 1 min..
(19:32:20) nirav: in java t would be interface
(19:32:29) nirav: with method f in it
(19:32:57) nirav: because in java you can’t return function pointers/ reference to blocks
(19:34:00) nirav: i was looking at this http://felix.sourceforge.net/
(19:34:05) nirav: sounds interesting
(19:34:41) me: in the above e.g. u return object of type ‘t’ right?
(19:34:49) nirav: yeah
(19:34:50) nirav: right
(19:35:33) nirav: where ‘t’ would be abstract class or interface to be nice
(19:35:47) me: and f() in that object uses the local variables declared in the outer function..
(19:36:23) nirav: yeah
(19:36:50) me: I’ll try that in php.. should be possible..
(19:36:54) nirav: ofcourse
(19:37:10) nirav: this is common;y employed in high level OO langs
(19:37:17) me: hmm..
(19:38:49) me: what are the problems with the method u said..?
(19:39:10) nirav: problems?
(19:39:17) nirav: problem is
(19:39:31) nirav: its pretty verbose
(19:39:50) nirav: and you have to write more and more code defeating the purpose of lambda expressions
(19:40:00) me: ok
(19:40:30) nirav: if i can directly express what i want to do in a lambda expression, i don’t need that ‘t’ and that ‘f’ declaration
(19:41:12) nirav: this way of creating closure is synthetic
(19:41:19) me: hmm..
(19:41:59) me: as in javascript support for inner functions and ability to return function references seems to be a better way..
(19:42:32) nirav: same is the case with python, ruby, scheme and many other lang which supports it
(19:42:38) me: hmm..
(19:42:58) nirav: java apparently supports it with the help of anonymous inner function but there are lot of problems

Post Index



  • Created a root folder named projectserver for storing all the test cases.
  • Created a test case named TestOfConnection to test the connection to the directory server. This test case is placed in a sub-folder called connection within the projectserver folder.
  • Created a test case named TestOfLoginProcess to test the authentication mechanism. This is placed in folder called auth in projectserver folder.

The servers sends responses in XML format. So We have a class that parses these responses into php objects for further usage. The possible responses from server are success xml, failure xml and information xml.

  • Created a test case named TestOfResponseParser to test the response parser class. This is placed in a folder called responseparser within the projectserver folder. This test case consists of various passes that feed xml strings to the parser and assert the return values for expected output.

Now we start testing the actual business logic. I called the class for project management as ProjectMgmt. We need to test the various usage scenarios of this class. Following is the initial set of methods I added to the test case TestOfProjects.











While developing these cases I felt that I was moving in bits and pieces and made sure that everything is working fine. But when the variety of cases started to rise I sensed a flaw in this order of test passes. Before I explain what I felt wrong with the above ordering let me put forward the reasoning behind why I laid them out that way.

I actually wanted to test the create project scenario first. I wanted to check that the project is successfully created in the directory server. I created the method testAddProject and saw that it failed because the method to create a project did not exist. Then I create a method to create a project. Now, while coding the logic for this method I realized I need to first check if the project already existed, may be a projectExists method. So I felt I should test the projectExists method first before createProject method. Similarly, due to the limitation of the server to check for a single project I had to get all the projects first to check if a particular project exists or not. So I felt I need to check getAllProjects first before testing projectExists. [well, this could be an absurd approach but this is how I naturally felt to develop]. So this is how I justify the ordering of first three passes above.

While I was pondering over the correctness of this approach I also refactored the project management classes when I was half through the test cases. I immediately saw the benefits. After modifying the code I rerun the tests and saw some of them failing. I fixed them and saw the green signal and proceeded for further test cases.

Now this is why I felt the ordering of the passes was wrong. The test cases always work on dummy information. Here I tested projectExists before createProject because I didn’t want to use projectExists inside createProject without testing it. I manually create a project in the directory server and check that the projectExists function works fine. Then I proceed to createProject method. Suppose I finished all test cases and put the test aside. After somedays may be I will need to rerun the tests. Suppose the dummy information that I manually fed into the directory server to test projectExists has been removed before I rerun the scripts the related test pass will fail. Should it fail in the absense of such information? I feel It shouldn’t because removing manually entered data doesn’t show any flaw in the method body (the unit to test). So I felt, its better to make the entire testcase atomic.

To make the test case atomic means that the test case will leave the external systems like the directory server in the same state as it was before it had begun to run. For this to happen, there shouldn’t be any manual intervension. There is a tradeoff here. To accomplish this atomicity, while coding the createProject method I should have had to put a projectExists method without first testing it. Any better way to do this?

I felt that by ordering the test passes in such a way that Creation methods are tested first, then querying methods, then modifying methods and finally deleting methods we can maintain the directory server in the state that it was before the test was run. The entire test case will use the project that was created by itself and delete it at the end.

How (im)proper is this approach? Any flaws in the approach?

Tags: ,

Problem: [The further postings would be based on this problem description.]

There are Projects, Sub-projects, users who can be assigned to projects and subset of those users can be assigned to sub-projects. I tried developing a solution for this using the test first approach.

Tools: PHP, SimpleTest, LDAP, Server(it talks to the LDAP server and operates over it)

Tags: ,

This approach to software development wherein we begin by writing tests is diametrical to the popular notion of the process. Popular view drives us to develop first and test later. TDD or the Test First Approach motivates us to write the tests first, watch them fail, develop only so much as is needed to see the test pass and repeat the cycle until the requirement is fulfilled and you are satisfied with your art. In case you are not satisfied with your art, refactor it and repeat the cycle. This seems to be tedius but only until we start doing it along with an insight on what we are getting out of it.

I’ve never been satisfied with the way I develop in PHP. Especially when a friend of mine, while talking about his experience with TDD, stated emphatically that he feels confident about his code with pre-written tests to prove his point. I never had that confidence. I thrive to craft my application well but there are other grave concerns than crafting the code. What if our assumptions while development change, what if the application environment has changed? How do we make sure that all parts of the system are working properly after the introduction of such changes. Do we manually browse all parts of the sytem to check that? How exhaustive is the manual approach? TDD answers these questions.

TDD enables us to visualize what we want to code. The tests that we develop is a kind of system flow, a flow that can be automatically executed. To ensure that it is exhaustive we should proceed minimally by coding only that much as is required to realize our current vision of the task. The moment we deviate from this minimalistic approach we miss some parts of the system, we start assuming and a little introspection would justify how dangerous our assumptions could be.

While I am learing TDD I hold a client’s (the client code in the application) view of the system. I try to develop test cases by forseeing on how I would be using that piece of code while working on other parts of the application. For e.g. If I am developing a class to parse some custom XML format for the application I would develop tests by first thinking about how I will be using this parser, various scenarios that employ this class to parse the format. My test will also include straight-forward cases to check output for particular set of inputs to an operation.

Proceeding in this way I sometimes feel that I’ve not structured the application correctly, probably I need to move the code to another component for better reusability, may be I can combine some common tasks into an utility class. When I feel so, I implement the changes and rerun the tests and see where it breaks, fix those bugs and move ahead.

The process appears to be slow but in reality if consider we the time we spend on hunting for bugs and resolve them at later stages we will be convinced that the test first approach is infact more productive. In his interview with Bill Venners, Martin Fowler says “There’s an impossible-to-express quality about test-first design that gives you a sense of unhurriedness. You are actually moving very quickly, but there’s an unhurriedness because you are creating little micro-goals for yourself and satisfying them“. He named this process of focusing on single aspect at a time as Monological Thinking.