SitePoint Sponsor

User Tag List

Results 1 to 14 of 14
  1. #1
    SitePoint Enthusiast
    Join Date
    Jul 2006
    Location
    South Dakota
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Getting Started with TDD

    Hello everyone,

    This is probably my first post in PAD, and after reading several threads and trying some stuff, I must say that I am "test infected." I have been working with SimpleTest and learning to use it over the past week and trying to use TDD to develop a new framework for myself.

    I have also been looking at Dependency Injection as well as a possible solution for allowing the ability to have plugins within the framework so that I can keep the framework small and tight.

    So here is my dilemma; I'm so used to knowing where my requirements are and developing an entire application that I want to start my framework with that thought. But XP says to use stories and work in iterations. I know that the framework will eventually use something like Phemto, Pico, or my own DI tool, but that if I work in small iterations as to what has to be done for an iteration release, then this would be toward the end of the product release and might cause grief implementing it at a later stage.

    The customer in this case is myself, and this project is my way of learning both TDD, XP/agile programming techniques, and the use of DI. I've been used to working for others over the past several years that only want things done in a procedural way and are afraid to use OOP in their applications. So this is my time to just do it myself and move away from what seems to be an endless cycle of buggy applications.

    I guess that I would see my first iteration as getting the UI to display as it will be where I see what is going on with the rest of the framework. This is one place that I see DI in use later on as the UI can display a web page, pdf file, XML or any other possibility as defined by the application that will use the framework. Since XP says work in iterations and only code what is needed and nothing more, then DI is not needed for probably the first 4 or 5 iterations at least, thus shouldn't be even thought of. For those of use that use XP/agile techniques, how do you determine what a good starting point is?

    Sorry if this is long, I'm just trying to wrap my head around these different techniques.

  2. #2
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The beauty of the DI pattern is that you don't need a container to do it. So, write using DI first, then introduce the container when you need it. I wrote an article on this for php | arch, the overlying philosophy of which I describe briefly on my blog.

  3. #3
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by teddarling View Post
    So here is my dilemma; I'm so used to knowing where my requirements are and developing an entire application that I want to start my framework with that thought.
    As a transition, record your requirements anyway. The difference is starting with just one of them, and putting the others out of your mind while you code. Done this way you'll be able to look back on that requirements list and suffer the full horror of how little of it was correct .

    Actually, I like having a bunch of requirements. It means we can have a prototype schedule, a few starting acceptance tests and can make a good stab at prioritising the most important stories. We don't invest a huge effort in them, though. The main task is getting a few good first stories.

    Quote Originally Posted by teddarling View Post
    I know that the framework will eventually use something like Phemto, Pico, or my own DI tool, but that if I work in small iterations as to what has to be done for an iteration release, then this would be toward the end of the product release and might cause grief implementing it at a later stage.
    How do you know?

    If you do "know" then experience trumps YAGNI. In that case a more ordered approach will be more efficient. Any amount of doubt and I would delay the decision. This is the basics of option trading.

    You have an option to use DI, just like a share option. An option is more valuable than the actual shares, because you can wait and see. It's never less valuable than the shares, because you can exercise the option at any time.

    Because options have value, you want to hold on to them as long as possible. You can delay the use of DI (or ServiceLocator or Registry) just by making dependencies explicitly passed. Or, if you do use the new operator, by having small, easily refactorable code so that you can move the construction around later.

    Quote Originally Posted by teddarling View Post
    I guess that I would see my first iteration as getting the UI to display as it will be where I see what is going on with the rest of the framework.
    No, this is phased delivery. Say that you make splendid progress on the UI. From that, how do you extrapolate to measuring your progress on the DB architecture? You can't. It's chalk and cheese.

    Rather than chop your timeline the same way as your layering, instead cut a thin slice through the whole stack. Do a user visible feature. Do it without security, authentication, etc. Do it crudely as necessary to fit easily into an iteration.

    Don't worry about getting the stack completely wrong. It will be so simple that you can introduce better layering in later iterations. It will be done so quickly that you can throw the whole lot away over the course of development.

    If that doesn't sound efficient, it's not supposed to. It's about risk management. It's a false belief that more up front planning reduces risk. It actually increases it, but it increases efficiency too. Less planning allows you to hit problems earlier and throw away your first efforts. More planning assumes that you won't hit the problem in the first place. That's a big risk if you don't know the domain very well.

    There is another aspect of XP that I've become aware of. It forms around three layers itself. There is the coding stuff (refactoring, TDD, pairing/review, metaphor, CRC). There is the project/iteration management stuff (acceptance tests, spikes, YAGNI) and then there is the interface with the stakeholders (stories, customer on site, planning game).

    You want bug avoidance and the software slow death, right. I reckon you will get a lot from the coding practices straight away. Probably less from the planning side until you have proven to yourself that you can change a design decision mid flow.

    Quote Originally Posted by teddarling View Post
    This is one place that I see DI in use later on as the UI can display a web page, pdf file, XML or any other possibility as defined by the application that will use the framework.
    This isn't DI. It's just a bunch of factories with a switch. DI is not for runtime decisions, but initial assembly decisions. It allows external modules to be easily incorporated at the start, even if they have radically different dependencies from what the framework/app. expected originally.

    You are heading more in the ServiceLocator or PluginArchitecture direction.

    Quote Originally Posted by teddarling View Post
    For those of use that use XP/agile techniques, how do you determine what a good starting point is?
    Can you write an acceptance criteria/test for just one feature? Have a go now and I'll try to code to it.

    Quote Originally Posted by teddarling View Post
    Sorry if this is long, I'm just trying to wrap my head around these different techniques.
    The long ones are the most interesting .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  4. #4
    SitePoint Enthusiast
    Join Date
    Jul 2006
    Location
    South Dakota
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thank you both for some great information. It really is valuable and it's great to hear from people that do so much.

    Quote Originally Posted by Selkirk
    So, write using DI first, then introduce the container when you need it
    Pre-TDD learning I certainly would have. I guess my question is, does TDD and YAGNI allow for that type of approach. I know that Marcus addresses that issue. In my case though, I don't have experience in DI to say whether or not I will need it. I just have my desire to learn about it as a reason that I have added it to my requirements.

    Quote Originally Posted by lastcraft
    How do you know?

    If you do "know" then experience trumps YAGNI. In that case a more ordered approach will be more efficient. Any amount of doubt and I would delay the decision. This is the basics of option trading.
    I know because I am using this project as an excuse to learn about DI . I understand that it may not be the most perfect use of DI, but I do know that other posts have mentioned a good framework as a probable place for the use of DI. In this case it's not the experience or lack thereof, but the gaining of experience that I'm after.

    Perhaps though I can just look at a small project to learn the use of it, instead of a framework that I plan on using to build all further projects (It has reduced coding time to about 1/4 of what it was before I built one where I work in ASP). It also seems that the framework I helped build with ASP uses similar ideas, though not quite the way I have seen Phemto or Pico built. I can see where it would reduce passing a lot of dependencies in the constructor.

    Quote Originally Posted by lastcraft
    No, this is phased delivery. Say that you make splendid progress on the UI. From that, how do you extrapolate to measuring your progress on the DB architecture? You can't. It's chalk and cheese.

    Rather than chop your timeline the same way as your layering, instead cut a thin slice through the whole stack. Do a user visible feature. Do it without security, authentication, etc. Do it crudely as necessary to fit easily into an iteration.

    Don't worry about getting the stack completely wrong. It will be so simple that you can introduce better layering in later iterations. It will be done so quickly that you can throw the whole lot away over the course of development.
    So you're talking basically like if I want a shopping cart, build the categories so that you can perform CRUD and display lists. Then go to CRUD/list products, then CRUD product attributes, then cart, etc, etc... Is this correct?

    Quote Originally Posted by lastcraft
    It's a false belief that more up front planning reduces risk. It actually increases it, but it increases efficiency too. Less planning allows you to hit problems earlier and throw away your first efforts.
    Man have I lived through this. I think that's why I really want to get into TDD. Just messing with it over the past week has opened my eyes. I can see the days of spending several weeks just planning going out the window. (Before anyone goes off about this, I do still see a need for at least thinking about the areas that need to be developed.) It almost seems that TDD would help improve morale seeing that there is progress right away instead of waiting weeks/months on large applications.

    Quote Originally Posted by lastcraft
    You want bug avoidance and the software slow death, right. I reckon you will get a lot from the coding practices straight away. Probably less from the planning side until you have proven to yourself that you can change a design decision mid flow.
    Does it really work that well? I know changing mid-flow with How I've worked in the past has been a nightmare.

    Quote Originally Posted by lastcraft
    This isn't DI. It's just a bunch of factories with a switch. DI is not for runtime decisions, but initial assembly decisions. It allows external modules to be easily incorporated at the start, even if they have radically different dependencies from what the framework/app. expected originally.
    I want external modules to be easily incorporated into the system. I would like to get it to the point were I can implement other people applications through the framework. Kind of like how many people try to integrate Vbulletin, phpBB, WordPress and others amongst each other. But I would like to be able to do it without actually changing any code in those other apps like everyone else has to. I guess from what I see, my applications/web sites can have their own functionality that wraps that of the other apps by using DI. And I guess I get the impression that DI can be a way to allow for extensibility of other peoples libraries/applications without changing their code.

    Quote Originally Posted by lastcraft
    Can you write an acceptance criteria/test for just one feature? Have a go now and I'll try to code to it.
    Here are the beginnings of tests for my primary file that will run everything. It kind of starts with a settings class. I had gotten to here and started on my settings test so that I can write a settings class. I am starting to jump between the two now. Should I be with TDD or should I get everything set up in my settings, parser, db classes, etc as I get to them?

    PHP Code:
    class TestCore extends UnitTestCase
    {
        function 
    TestCore ()
        {
            
    $this->UnitTestCase('CoreTests');
        }

        function 
    TestDsDefined()
        {
            
    $this->assertTrue(defined('DS'));
        }

        function 
    TestCoreDefined()
        {
            
    $this->assertTrue(defined('CORE_PATH'));
        }

        function 
    TestAppPathDefined()
        {
            
    $this->assertTrue(defined('APP_PATH'));
            
    $this->assertEqual(APP_PATHdirname(CORE_PATH) . DS 'application');
        }

        function 
    TestAppSettingsDefined()
        {
        
    $this->assertTrue(defined('APP_SETTINGS'));
        
    $this->assertEqual(APP_SETTINGSAPP_PATH DS 'settings/appSettings.xml');
        }
        
        function 
    TestIncludePathSet()
        {
        
    $includePattern CORE_PATH PATH_SEPARATOR CORE_PATH DS 'coreClasses';
        
    $includePattern .= PATH_SEPARATOR APP_PATH;
        
    $includePattern str_replace('\\''\\\\'$includePattern);
        
    $this->assertPattern('/'.$includePattern.'/i'ini_get('include_path'));
        }

        function 
    TestAppSettingsExists()
        {
        
    $this->assertTrue(file_exists(APP_SETTINGS));
        }

         function 
    TestInitializeSettings()
        {
            
    $appSettings = & new coreSettings(APP_SETTINGS);
            
    $this->assertIsA($appSettings'coreSettings');
        }

    I want to have two classes, one that uses XML files for settings and one that uses .ini files. I guess this is where I started to see that DI might be a good possibility for integrating. Would you work one type at a time until you decide to integrate the other when using TDD?

    This is what I had started to write as I was looking at doing this simiilar to how I've done things in the past. That's when I decided to try asking my questions. While I'm showing this, does it actually make sense to test in this much detail, down to the constants, or should tests be primarily on the classes that are implemented?

  5. #5
    SitePoint Enthusiast
    Join Date
    Jul 2006
    Location
    South Dakota
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My last post I talked about using a settings file. Now that I think about it and TDD, I probably shouldn't be looking at that now. I guess that I'm extremely used to using a settings file in most projects and it is normally one of the first things that I implement.

    I really do want to do this project from the start using TDD as again it is to be my environment to learn multiple concepts as it is something that I do not have a hard fast approaching deadline on.

    I'm a little confused as to where I really should start and wonder if using a framework to try learning TDD and everything else is where I should start as a framework really doesn't have a lot to do with displaying actual data, just performing actions as requested, whether it is displaying a page, messing with data, making calculations or just running some action in the background. The end result is not so clear.

    What are your thoughts on trying to learn these by building a framework? Should I be looking at some sort of concrete application that I want to build that will help me learn about TDD?

  6. #6
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by teddarling View Post
    I just have my desire to learn about it as a reason that I have added it to my requirements.
    The agile stuff is all about delivering a successful project over the long term. One of my criticisms of it is that it doesn't address learning and developer skill. It's all siphoned off into the "spike test" and pairing. No further guidance is given. Yet developer skill is probably the greatest factor in the technical success of a project.

    Having defined your project, you can watch agile deliver it. Learning DI is probably something you'll have to do separately. Also DI is a solution. You probably want to learn about the problem area and then evaluate a range of solutions. It's knowing the trade-offs that has the value.

    Quote Originally Posted by teddarling View Post
    I understand that it may not be the most perfect use of DI, but I do know that other posts have mentioned a good framework as a probable place for the use of DI.
    It would be. It's a bad one for TDD. Most agile people would write applications, then pull the framework out of that family. Rails is a good example. It was commonality over several apps.

    Quote Originally Posted by teddarling View Post
    So you're talking basically like if I want a shopping cart, build the categories so that you can perform CRUD and display lists. Then go to CRUD/list products, then CRUD product attributes, then cart, etc, etc... Is this correct?
    No . That's a structural decomposition built around what you think the code will look like. You are probably right, but let's put that aside for the moment.

    Let's take one action by the user in the form of a story. Let's say that they can purchase an item. I'll assume that this is some kind of catalogue site. As it's a framework it will have to be pretty generic. Let's say they are buying computer parts - a mouse perhaps. I have one plugged in my Mac laptop right now. It's an Advent Wifi jobbie with a USB thingy.

    So the story goes:
    I go to the "Advent Wifi jobbie with a USB thingy" page and click order. The stock control system is notified of the sale."

    Hm. The stock control system could be anything. That will mean facading it for the test at least. Here is my acceptance test for the feature...
    PHP Code:
    class WebsiteDeliversOrdersToStockControl extends WebTestCase {
        function 
    setUp() {
            
    $this->installTestApplication();
        }

        function 
    tearDown() {
            
    $this->uninstallTestApplication();
        }

        function 
    testBuyingMouseDecrementsStock() {
            
    $this->setStock("Advent Wifi jobbie with a USB thingy"1);
            
    $this->get('http://localhost/test_application/advent_wifi_jobbie.php');
            
    $this->click('Order');
            
    $this->assertEqual(
                    
    $this->getStock("Advent Wifi jobbie with a USB thingy",
                    
    0);
        }

        ...

    Obviously this needs a lot of filling out and will change later as the application stack grows. Right now we just have to get the test to pass. Here is my implementation of clearing down the test app...
    PHP Code:
    function installTestApplication() {
        `
    rm -f ../temporary/*`;
    }

    function 
    uninstallTestApplication() {
        `
    rm -f ../temporary/*`;

    My idea of YAGNI stock control...
    PHP Code:
    function setStock($item$quantity) {
        
    file_put_contents("../temporary/$item"$quantity);
    }

    function 
    getStock($item) {
        return 
    file_get_contents("../temporary/$item");

    Anyway, it's easy to get this test to pass with a simple script...
    PHP Code:
    <?php
    if (isset($_POST['order'])) {
        
    file_put_contents(
                
    "../temporary/Advent Wifi jobbie with a USB thingy",
                
    file_get_contents("../temporary/Advent Wifi jobbie with a USB thingy") - 1);
    }
    ?>
    <html>
        <form>
            <input type="submit" name="order" value="Order"/>
        </form>
    </html>
    I doubt if a single line of this test will survive even the first iteration. Doesn't matter. In writing it I have identified a ton of problems to solve...

    1) How do we tell the application what stock control system to use on installation? DI? I think this is a good choice here.

    2) How does the stock control know paths, passwords, etc? Looks like we need your Settings class after all. The installer can set this up, and that makes it accessible from the test. I often write acceptance tests that completely reinstall the app. on each test.

    3) How does our sample application actually install? This doesn't affect our framework directly, but I doubt we want to hamstring the app. developer by forcing MySQL to be set up for example. Say it will be a web based installer. that would make our testing easier as we can go straight to the install page and configure the settings using the browser.

    4) Is the StockControl an interface? That would make the test cleaner at least. I reckon yes.

    Any of these four would make a good first refactoring.

    Note that this is an acceptance test. It doesn't have to be working all the time or to run very quickly. This sort of test would run as part of a nightly build. The unit tests start once we dig a little deeper.

    Quote Originally Posted by teddarling View Post
    Does it really work that well? I know changing mid-flow with How I've worked in the past has been a nightmare.
    Yes it does work, but only if you've got lean factored code with good test coverage. That last aspect is key. If I want to make a change, I can just do the change and see what tests fail. If it's a lot, I'll break it into smaller changes. That way the code is always under control.

    Quote Originally Posted by teddarling View Post
    Would you work one type at a time until you decide to integrate the other when using TDD?
    How do you know you need two?

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  7. #7
    SitePoint Enthusiast
    Join Date
    Jul 2006
    Location
    South Dakota
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thank you for your help Marcus, it's great to have help when learning about new concepts. I really do like how TDD works.

    Quote Originally Posted by lastcraft
    It would be. It's a bad one for TDD. Most agile people would write applications, then pull the framework out of that family. Rails is a good example. It was commonality over several apps.
    I guess that this is kind of where I see developing a framework as a useful project. Where I work now, I work with ASP and have worked with a co-worker to develop a new framework that the whole company is slowly moving toward. It has certainly helped with getting projects done four times faster for the simple ones and still getting bigger projects done in less time, though probably not as fast as there is still plenty of code to write.

    It's nice to be able to spend 1/2 hour running some setup scripts to get permissions and a basic admin area setup and get a framework that our designers can use to work with. That saves a couple days of coding in itself.

    Quote Originally Posted by lastcraft
    That's a structural decomposition built around what you think the code will look like. You are probably right, but let's put that aside for the moment.
    ...
    I go to the "Advent Wifi jobbie with a USB thingy" page and click order. The stock control system is notified of the sale."
    That seems simple for a user story. So the idea is to not write a story that says add/update/delete items from inventory, rather something like "when deleting a category for stock, place all stock associated with that category into the miscellaneous category so that it doesn't get lost." One specific action for the story. Am I getting this right?

    Quote Originally Posted by lastcraft
    1) How do we tell the application what stock control system to use on installation? DI? I think this is a good choice here.
    Would this be a good place for DI because you could have a file based, sql based, xml based stock control system that we use? DI is used because then we just need an interface that any of these could build a class from and use the interface for type hinting on the application. Is this correct? Or could we just as easily use a service locator to pass into the class to use?

    Quote Originally Posted by lastcraft
    3) How does our sample application actually install? This doesn't affect our framework directly, but I doubt we want to hamstring the app. developer by forcing MySQL to be set up for example.
    Right, I want to build the framework with the developer in mind and give them the ability to use their own system for creating recordsets, user security, settings, etc. That's why I also said that I would like two ways to initialize settings. I personally use both XML and INI for settings. I tend to shy away from too many constant, I just don't like the way that they look. Plus it seems easier to give someone a file that they can make changes to without doing a lot of
    PHP Code:
    if (!define('SOME_VAR'){
        
    //code

    type of stuff. It just seems cleaner for me I guess. Plus it makes it easier to make those settings changeable through a web interface. I can put the changable settings into a folder that is outside of the standard folders and *cough* make it writable *cough* if I have no other solutions available with a hosting provider.

    Quote Originally Posted by lastcraft
    Note that this is an acceptance test. It doesn't have to be working all the time or to run very quickly. This sort of test would run as part of a nightly build. The unit tests start once we dig a little deeper.
    So you start with a web based test first as you start to see what you are wanting in an application?

    What do you consider a nightly build? I guess to me PHP code is always able to run at any point. Is this just something that you do to make sure that tests are run before you finish at night, or that they run at least once daily? This just makes me think of a compiled language talking about builds.

    Also, it seems then that you are suggesting that it might be better to have an application idea (or two+) that I would like to create. Then use those applications as a basis for creating a framework? That sounds like it might be an easier way to learn TDD instead of jumping in to the middle of the Pacific.

  8. #8
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by teddarling View Post
    That seems simple for a user story.
    That's right. It's really just a single thread of execution. You can group the stories into full blown use cases if you like, with happy paths and failure paths. You would still end up breaking them down for the iteration though, so there is probably no point.

    Because they are a lightweight system, they come straight out of the stakeholder's mouth, the means of ensuring correctness is different. With use case driven approaches you would have an analyst consult stakeholders over several weeks to gather requirements. With agile we turn that on it's head. We get a system out quick and the stakeholders tell us what they really want after all. You still have to do all of that requirements gathering work, but you are doing it concurrently with a running application.

    Agile doesn't get you off of the hook with this stuff. It just changes the order.

    Quote Originally Posted by teddarling View Post
    So the idea is to not write a story that says add/update/delete items from inventory, rather something like "when deleting a category for stock, place all stock associated with that category into the miscellaneous category so that it doesn't get lost." One specific action for the story. Am I getting this right?
    If you can, the result should be user visible. If the miscellaneous category is visible to the customer (that includes the administrators of the app.), then that's a valid story.

    I do find that I cannot always make a story customer visible - infrastructure work for example. Those types of stories should be the exception though.

    Quote Originally Posted by teddarling View Post
    Would this be a good place for DI because you could have a file based, sql based, xml based stock control system that we use? DI is used because then we just need an interface that any of these could build a class from and use the interface for type hinting on the application. Is this correct? Or could we just as easily use a service locator to pass into the class to use?
    It's a good candidate, because they have a common interface, but totally different dependencies. I couldn't make any final decision at this time. As you say, you will probably go 4-5 iterations before you know.

    Quote Originally Posted by teddarling View Post
    That's why I also said that I would like two ways to initialize settings. I personally use both XML and INI for settings. I tend to shy away from too many constant, I just don't like the way that they look.
    How do you know that you need any?

    Quote Originally Posted by teddarling View Post
    So you start with a web based test first as you start to see what you are wanting in an application?
    Yes. It doesn't have to be automated (although that's my preference), but it should be exceptionally concrete.

    Quote Originally Posted by teddarling View Post
    What do you consider a nightly build? I guess to me PHP code is always able to run at any point.
    At Wordtracker the full test suite takes over 20 minutes to install and run. This runs overnight and sends us a mail. While your project is small, you can just run an all_tests.php file before every check-in.

    Quote Originally Posted by teddarling View Post
    Also, it seems then that you are suggesting that it might be better to have an application idea (or two+) that I would like to create. Then use those applications as a basis for creating a framework?
    That would be my preference. As your usability work will involve concrete examples (you surveyed your ASP users, right?), these will be easier to handle with concrete examples already in the test suite.

    It depends how well you understand your users and your requirements.

    Quote Originally Posted by teddarling View Post
    That sounds like it might be an easier way to learn TDD instead of jumping in to the middle of the Pacific.
    Yeah .

    Alternately, just bring in those bits of agile that you need now. You probably want to be trying it out on real work anyway.

    You could gather conventional requirements, write some acceptance tests and plan stuff. Then code the lower level components with TDD/refactoring. That moves the risk from screwing up your processes, to wasting a lot of time on dumb requirements. That may be a profitable trade.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  9. #9
    SitePoint Enthusiast
    Join Date
    Jul 2006
    Location
    South Dakota
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thank you Marcus for your help in getting a grasp on this.

    And you're right, I may not need a settings file per se for a project, I just tend to use them a lot for the size of projects that I work on. Tough there have been a few smaller projects that never have needed on. I was looking at it from the point of view of a framework that works fo getting most of my projects off to a quick start.

    Quote Originally Posted by lastcraft
    While your project is small, you can just run an all_tests.php file before every check-in.
    Do you check in when you complete a specific file, or do you work on a couple of files and do a check in once a day or every couple of hours? i've been doing it mostly at the end of the day, though if I have to change a file that is complete, but needs a small change, I make the change, test it and check it in then.

    Quote Originally Posted by lastcraft
    Alternately, just bring in those bits of agile that you need now. You probably want to be trying it out on real work anyway.
    What I'm doing with PHP these days is going to be from scratch anyway, so I want to start with TDD from the beginning and all the requirements are my own (I'm the customer as I can't exactly go out trying to get web clients working for an agency). So this is the perfect time for me to start using and learning the right way to use TDD.

    Off Topic:


    Do you know of any good standard ASP (3.0) unit test tools? ASPUnit doesn't seem to have a lot of ability.

  10. #10
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by teddarling View Post
    Do you check in when you complete a specific file, or do you work on a couple of files and do a check in once a day or every couple of hours?
    Hourly or less.

    Quote Originally Posted by teddarling View Post
    i
    Off Topic:


    Do you know of any good standard ASP (3.0) unit test tools? ASPUnit doesn't seem to have a lot of ability.
    Sorry, no idea. Does NUnit only work with C#? Doesn't Visual Studio bundle this stuff now?

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  11. #11
    SitePoint Enthusiast
    Join Date
    Jul 2006
    Location
    South Dakota
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Marcus, either you go to bed late or get up early if you're in London. Gone are those days for me. Anyway thank you for all of your input, it has been fantastic.

    I think that hourly makes sense from a purely I don't want to have to figure out what I did an hour ago that I broke so bad point of view.

    I'm sure that I'll have plenty of other questions as I continue to learn this stuff, but I'm going to decide on an app to build and start with what I have learned here and probably leave DI for another thread and time as I am confident in testing as I'm sure that will come in handy.

    Again, Thank you,
    Ted

  12. #12
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    It's 3am . Luckily the wife and kids are at the in-laws . For a brief couple of days I can pretend it's like the old days. Sigh...

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  13. #13
    SitePoint Enthusiast
    Join Date
    Jul 2006
    Location
    South Dakota
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oh yes, the old days of never sleeping. How I long for them.

    I didn't think that I would have another question so quick about TDD. I'm used to setting up my DB tables using CASE tools ERDs and such. If you test things and implement them as you need them, do you create your tables, relationships, etc as you need them?

  14. #14
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by teddarling View Post
    I'm used to setting up my DB tables using CASE tools ERDs and such. If you test things and implement them as you need them, do you create your tables, relationships, etc as you need them?
    If I can.

    It depends on the cost of change. If you have good tools to migrate schemas, or the application is not deployed yet, then just create them as you go. It's easy so long as the only data is test data.

    Once you have a load of live data, you have to get a bit cagey. You can go the whole hog and write Migration classes and stuff for changing live schemas. This beats writing porting scripts afresh each time, but is still ongoing work.

    Alternately do some upfront work to get the schema mostly right, or at least flexible enough. As data tends to be more susceptible to analysis, you might win with this trade. Database tools just haven't caught up with agile approaches yet.

    As this is a pet project and a framework, it sounds like you will be mercifully protected from live data. You can go agile all the way. You are lucky.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •