News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Snack Overflow:
Unit testing static calls without refactoring the world in php
February 27, 2015 @ 11:55:06

The "Snack Overflow" blog (from tech.graze.com) has a recent post sharing some suggestions to help unit test static calls without having to "refactor the world" away from them.

Imagine you have a situation [using a static method call] in some legacy code. Currently we can't unit test this as we can't mock out the doSomethingElse() call. So what do we do? Well we have two options really [...] neither of which is very appealing. [...] There is, however, a third option that gains us the ability to unit test Foo without having to touch Bar at all.

This option involves creating a "proxy" object of the "Bar" class that's non-static and only returns the result of the previous class' static method. You can then correctly mock that class and return the result in a more self-contained way. He lists a few caveats with this method including the fact that it could lead to a lot of proxy objects if there are a lot of static methods to replicate.

0 comments voice your opinion now!
unittest static method refactor proxy object mock tutorial

Link: http://tech.graze.com/2015/02/26/unit-testing-static-calls-without-refactoring-the-world-in-php/

Mathias Verraes:
How Much Testing is Too Much?
January 02, 2015 @ 11:55:43

In his latest post Mathias Verraes poses the question of how much testing is too much? At what point does testing actually become less useful and how much you really need.

Figuring out how much unit tests you need to write, can be tricky, especially if you are new to Test-Driven Development. Some teams strive for 100% code coverage. Some open source projects even announce their test coverage on their GitHub profiles - as if coverage is an indicator of quality. Coverage only measures the lines of code that are executed by the test suite. It doesn't tell you whether the outcome of the execution is actually tested, let alone how valuable that test is. Because of that, code coverage of your entire code base is a pretty lousy metric.

He suggests that the "it depends" answer to "how much testing is enough" question just isn't good enough. He puts most of this in the context of TDD (where testing is built-in to the development time) but some of the thoughts could apply to post-code testing as well. He also talks about over-design and how it relates to refactoring with deeper insight. Finally, he talks about a subject not mentioned much in testing articles - when to delete tests.

0 comments voice your opinion now!
unittest testdrivendevelopment tdd too much overdesign refactor delete

Link: http://verraes.net/2014/12/how-much-testing-is-too-much/

NetTuts.com:
Refactoring Legacy Code - Part 11 The End?
October 27, 2014 @ 13:36:14

NetTuts.com has completed their series on refactoring with the posting of part eleven today: "The End?" This post finishes off a series where they've moved from the most basic level of testing out to a complex set of tests that can ensure your code's quality and functionality even after making their recommended refactoring changes.

In our previous lesson we've learned a new way to understand and make code better by extracting till we drop. While that tutorial was a good way to learn the techniques, it was hardly the ideal example to understand the benefits of it. In this lesson we will extract till we drop on all of our trivia game related code and we will analyze the final result.

They start off by "attacking the longest method" (wasCorrectlyAnswered) by starting the testing process. They make some simple checks to ensure the output is correct for various circumstances and values. With these tests in place, they safely refactor the method, splitting it up into functional pieces and completely dropping the method in favor of more targeted handling. They finish off the post with a look at some final results and comparing the refactored code with the original on things like lines of code, complexity, dependencies and structure (using this tool).

0 comments voice your opinion now!
refactor legacy code part11 series end correctly answered

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-11-the-end--cms-22476

NetTuts.com:
Refactoring Legacy Code - Part 10 Dissecting Long Methods with Extractions
September 19, 2014 @ 09:41:54

NetTuts.com is back with the latest part of their "Refactoring Legacy Code" series for PHP. In this latest article (part 10) they work on pulling apart longer methods into smaller, more manageable chunks.

In the sixth part of our series we talked about attacking long methods by leveraging on pair programming and viewing code from different levels. We continuously zoomed in and out, and observed both small things like naming as well as form and indentation. Today, we will take another approach: We will assume we are alone, no colleague or pair to help us. We will use a technique called "Extract till you drop" that breaks code in very small pieces. We will make all the efforts we can to make these pieces as easy to understand as possible so the future us, or any other programmer will be able to easily understand them.

This "extract 'till you drop" mentality (from Robert Martin) has you look at a piece of code and find the logic and lines that can be split out and isolated without removing functionality and interaction. They include some random code from a Stack Overflow post (checking if a number is a prime) and show how to split it out, making the logic and structure less complex and more understandable. They start with a unit test to ensure the result is the same post-refactor and fixing a few bugs along the way. They split it out into two different methods and move it from a more linear approach to something recursive.

0 comments voice your opinion now!
tutorial refactor legacy code part10 series extract method

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-10-dissecting-long-methods-with-extractions--cms-22182

NetTuts.com:
Refactoring Legacy Code Part 9 - Analyzing Concerns
July 24, 2014 @ 11:27:56

The NetTuts.com site has posted part nine in their series sharing helpful hints and methods for refactoring legacy code. In this new post they continue on with their example application and look at where methods should be moved to/created and mocking in their tests.

In this tutorial, we will continue to focus on our business logic. We will evaluate if RunnerFunctions.php belongs to a class and if so, to which class? We will think about concerns and where methods belong. Finally, we will learn a little bit more about the concept of mocking.

They show how to move some of the "Runner" functions from procedural to OOP, integrating them with some of the classes and methods that already exist. Tests are also included showing how it all links together. From there they get into concerns about the placement of functionality and how that relates to the work at hand. They also use Mockery to mock out some of the needed objects in their tests for the new structure.

0 comments voice your opinion now!
refactor legacy code series part6 concerns functionality mock unittest

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-9-analyzing-concerns--cms-21760

NetTuts.com:
Refactoring Legacy Code Part 8 - Inverting Dependencies for a Clean Architecture
July 10, 2014 @ 11:04:13

NetTuts.com has posted part eight in their series looking at refactoring legacy code - Inverting Dependencies for a Clean Architecture. In this latest post they move away from just refactoring the code and start to look more at fixing the architecture of the application.

Old code. Ugly code. Complicated code. Spaghetti code. Gibberish nonsense. In two words, Legacy Code. This is a series that will help you work and deal with it. It's now time to talk about architecture and how we organize our newly found layers of code. It's time to take our application and try to map it to theoretical architectural design.

They look at the current structure of the code (well, of their refactored version) and how to apply the Dependency Inversion Principle (part of the SOLID methodology) via interfaces. The code is included for the refactor as well as tests to add to their "Golden Master" test suite to ensure continued correct functionality.

0 comments voice your opinion now!
refactor legacy code series part8 inverting dependencies

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-8-inverting-dependencies-for-a-clean-architecture--cms-21659

NetTuts.com:
Refactoring Legacy Code Part 7 - Identifying the Presentation Layer
July 03, 2014 @ 12:57:39

NetTuts.com has posted part seven in their "Refactoring Legacy Code" series today, continuing on with the refactor of their example application to improve maintainability and testability. In this latest article they focus in on the presentation layer.

In this seventh chapter of our refactoring tutorials, we will do a different type of refactoring. We observed in the past lessons that there is presentation related code scattered all over our legacy code. We will try to identify all the presentation related code that we can and we will then take the necessary steps to separate it from business logic.

The tutorial starts with a look at the Single Responsibility Principle (part of the SOLID design principles) and how it relates to the idea of clean architecture. They continue down the path of separating out the business logic and isolating it from the presentation layer (the display* handling). They create an "Extract" class that combines the logic and presentation though combination functionality. They walk you through the code, showing the changes you'll need to make and the tests to match.

0 comments voice your opinion now!
refactor legacy code series part7 presentation layer isolating

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-7-identifying-the-presentation-layer--cms-21593

Leonid Mamchenkov:
CakePHP 3, here we go again.
July 02, 2014 @ 13:18:55

In this new post Leonid Mamchenkov looks at the latest version of a PHP framework that's been around since the PHP4 days, CakePHP, and some of the improvements that will come with version three.

Currently, I am at the start of a couple of projects, which require a bit of the future support. CakePHP 2.x can handle the job now, but I'm looking more into the next 3-5 years. And that's why I'm looking at CakePHP 3, which is still in the early development stage, with an alpha release coming not too long from now (have a look at the CakePHP 3 roadmap document). Let's have a look at the high level goals for CakePHP 3.

Among the items he mentions are things like:

  • The adoption of broader PHP community standards
  • An increase in modularity
  • Developing for PHP 5.4+
  • Composer support (and using PSR-4 autoloading)
  • The removal of some more complex, brittle code in favor of simpler, easier to extend options

Check out the roadmap and migration guides for full information.

0 comments voice your opinion now!
cakephp v3 framework refactor features roadmap goals

Link: http://mamchenkov.net/wordpress/2014/07/01/cakephp-3-here-we-go-again/

NetTuts.com:
Refactoring Legacy Code Part 6 - Attacking Complex Methods
June 27, 2014 @ 13:17:37

The NetTuts.com site has posted the sixth part in their "Refactoring Legacy Code" series, this time with a focus on the more complex methods. They look at simplifying their contents and testing their various parts (better code coverage). The post is based completely on the contents of the previous five in the series, so if you haven't read up on those do that before starting.

In our previous five lessons we invested quite a lot of time in understanding our legacy system, in writing tests for whatever testable piece of code we could find. We reached a point to where we have quite a few tested methods but we still avoided the complex, hard to understand logic. It's now time for some serious coding.

The start with one of the more complex methods (roll) and work through it line-by-line to figure out what it's being given, how it's handling the data and what kinds of things it might return or modify inside. The break it down into to "parts" and figure out the right tests to write for each. With the method fully tested, they then start in on the refactor, teasing out various parts of the method into other methods and property changes. There's also a section at the end talking about pair programming and how it relates to good testing practices.

0 comments voice your opinion now!
refactor series tutorial part6 complex method unittest phpunit

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-6-attacking-complex-methods--cms-21522

Matthias Noback:
Symfony2 How to create framework independent controllers?
June 18, 2014 @ 09:15:16

Matthias Noback has a new post to his site today, the first part of a series, looking at making framework-independent controllers for use in a Symfony2 framework-based project.

The general belief is that controllers are the most tightly coupled classes in every application. Most of the time based on the request data, they fetch and/or store persistent data from/in some place, then turn the data into HTML, which serves as the response to the client who initially made the request. [...] In this post I demonstrate that this high level of coupling is definitely not necessary. I will show you how you can decrease coupling a lot by taking some simple steps. We will end with a controller that is reusable in different types of applications, e.g. a Silex application, or even a Drupal application.

In this first part he focuses on a few places where the common practices lead to some unnecessary coupling between the controller and framework:

  • Using the framework helper methods
  • Using dependency injection (manually injecting instead)
  • Making the controller a service instead

The next post in the series will look at the use of annotations and how to refactor them out of the controller to remove yet another coupling point.

0 comments voice your opinion now!
framework independent controller symfony2 tutorial refactor decouple

Link: http://php-and-symfony.matthiasnoback.nl/2014/06/how-to-create-framework-independent-controllers/


Community Events

Don't see your event here?
Let us know!


php7 community laravel conference series part2 composer introduction symfony example yii2 interview application api language project framework list podcast opinion

All content copyright, 2015 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework