Planet Drupal

Subscribe to flux Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Mis à jour : il y a 31 min 51 sec

Drupal Easy: DrupalEasy Podcast 160 - Shamed (Michelle Krejci - Automated Drupal Deployment)

mar, 04/08/2015 - 21:16
Download Podcast 160

Michelle Krejci (craychee), engineer at Palantir.net, joins Mike Anello, Ted Bowman, and Ryan Price to talk about grand Belgian statues, things in Chicago that only tourists love, why we're all confused about the thing called "continuous integration" and all the tools and technologies around it. Michelle breaks it all down for us and provides a reasonable entry point for beginners. Recent Drupal news, picks of the week, and five questions round out the rest of the episode.

read more

Catégories: Elsewhere

Shomeya: To hourly or not? How Block Billing is Changing EVERYTHING

mar, 04/08/2015 - 20:55

Everyone bills hourly, and as it turns out just about everyone hates it. This process makes clients feel cheated, and agencies exasperated.

At the end of the day there's usually at least a hint of disappointment in both how long it takes to get paid, and/or how much it all came to.

You come to expect that you are going to be disappointed 99% of the time. So most of us just cross our fingers and hope the project doesn't become hell for everyone at the end of the month.

But this makes zero sense. There is so much more we can do to change the way that we run our consultancies, and so this summer I began experimenting. (Note: Blocks for September are starting to book, so if you think this is for you at all, get in touch.)

I've considered block billing for years, but thought transitioning would be some dramatic ordeal. You know tell ALL the clients, change ALL the forms, and it was some work...but the start...the start was so so simple...

A little column in a table of rate options. I'd heard that competing against yourself was a good thing. So, I decided to list three price options for some new potential clients. Block billing just happened to be one of them. I even did this for a well established client, and guess what it worked there too!

The client ALWAYS chooses block billing. It's been kind of awesome. Because it turns out client's like to have a general idea of what they're getting too.

Would this work if I only offered block billing? Probably, but even then I would give options, control is such a fleeting thing on a web-project for clients give it anywhere you can.

Would this scale? If you scale the size of the block, say a week, this works well for even larger agencies. In fact I learned it from watching @brenandunn who's advice is aimed at consultants, but scales quite nicely to agencies as well.

The goal of block billing is to make the focus on the features of the project not on the time spent. This way the website, the users, you, AND the client all win. If the focus is only on the time spent, it's very easy to lose perspective quickly.

So here's how it works, and the awesome results.

Read more
Catégories: Elsewhere

Drupal Watchdog: Why is a Data Breach Like a HAZMAT Leak?

mar, 04/08/2015 - 19:44
Article

You just bought a beautiful new home. You spent a lot of money, so you want to get the most out of your investment by looking for opportunities to make it income-producing while residing in it. Along comes a friend with a novel idea. A local manufacturing company exceeded its monthly waste allotment and needs a new location to store its surplus HAZMAT material. This company will pay an extraordinary amount of money – $1,000 per barrel per month – to take up what would otherwise be unused space in your basement.

So... would you do it?

The potential of a massive passive income stream can be enticing. However, in this case, the risk you’d take on is enormous. What happens if the barrels are faulty – or they leak? What if they drop in transit – and crack open? What if there’s a natural disaster – a fire or a flood? How widespread might the damage be? Would you face fines for contaminating the environment? What about the resell value of the house? And if the waste leached out, how would it affect your family’s health?

The fact is that the possible damage is so severe that most cities, states, and counties forbid HAZMAT storage in residential property.

Credit Card Processing

Storing, processing, and transmitting payment card data also comes with potential risks and rewards.
On the one hand, adding an eCommerce component to a website can open up a sizable income stream, which the merchant can then use to grow the website or offset the initial build cost. However, the effects of credit card breach can be fatal to a business: customers may lose trust and take their business elsewhere; credit card companies may lose money from fraudulent charges; and the merchant may be required to pay for significant upgrades without the budget to do so – as well as face fines as high as $200 per credit card transaction affected.

Ouch!

Similar to managing hazardous materials, a single breach wipes out gains and even leaves the merchant stuck cleaning up the mess.

Catégories: Elsewhere

Shitiz Gag's Blog: [GSoC 2015: Hawk Authentication] Week 11: Improving user permission model

mar, 04/08/2015 - 16:50

Continuing from last week, the primary focus for me this week was to focus on the permissions for users and their credentials as provided by Hawk. This involved the following:

  1. Allowed admins to restrict individual role’s maximum number of credentials
  2. Created individual permissions for creating, viewing, updating, deleting and administrating hawk credentials
  3. Allowed administrators to make exceptions to certain users=

Allowed admins to restrict individual role’s maximum number of credentials

For Hawk, I have added a configuration form in Admin > Configuration area which allows admins to specify a maximum limit for every role having permission to have Hawk credentials, they can specify 0 for a role to have no limit. In case an user has multiple roles with limits, maximum limit will be used for that role.

For example: There are four roles: A, B, C, D and a user has: A, C, D. A has no limit, B has 2, C has 3 and D has 5. Since the user has A which has no limits, the user will also have no limits to the number of credentials they can have.

Created individual permissions for creating, viewing, updating, deleting and administrating hawk credentials

I have split each CRUD permission into it’s own separate entity and added a separate fifth permission which grants admin access to all hawk credentials and settings. The CRUD permissions apply to individual user’s credentials. An admin can restrict a role to have credentials but not create them, allowing creations only by administrators. They can restrict them the ability to edit their revoke permissions, but add credentials and so on so forth. Hawk admins automatically get all permissions as well as ability to view and edit other’s credentials.

Allowed administrators to make exceptions to certain users

This was the most time consuming part of this week’s sprint, any user having hawk administrator permission can now add, edit or delete any other user’s hawk credentials even if that user doesn’t have the required permission and the admin can also override the limit set for the roles. For example, if a user cannot delete credentials they can request an administrator to delete one for them or if a user cannot add credentials they can do the same. The reason it took quite a bit of time was because this required a little refactoring in the way Hawk handled forms and permissions. Previously everything was assumed to be in the context of current logged in user but that required changing to the user whose profile was being viewed.

For now that’s it for the week, next week I’ll focus on further improving the module. Maybe this time I’ll finally get the chance to implement unit tests unless some other idea pops up.

Thank you for reading!

Catégories: Elsewhere

Chromatic: How To Manage Your Drupal Patches with 'Drush Patch File'

mar, 04/08/2015 - 16:36
Patching Drupal

It's only a matter of time. You encounter a bug in Drupal core or a contributed module, search the web for the issue you are encountering and more often then not, you are not the first person that has encountered the issue. You find an issue on Drupal.org and if you are really lucky, there is a viable patch associated with it. Hopefully this patch will one day make it into a release, but this won't slow you down. You apply the patch, it fixes the bug and all is well with the world. That is until it comes time to this contrib module. Maybe a different developer is performing the update, or maybe it is just you months (years?) later. You don't neccesarily remember that you previously patched this specific module and when you update it, you unintentionally overwrite the patched fix, reintroducing the bug.

To lessen the chances of this occurring, we want to be able to track all of the patches that have been applied, and ensure that they are re-applied every time the underlying code has been updated.

The Old Way

In the past, we manually tracked patches in a directory at the top level of our git repository. Within this 'patches' directory, we have a folder for Drupal (core) patches and a folder for each contrib module that has had a patch applied. When a module is updated, it is up to the developer to consult this directory structure and identify any patches that may need to be reapplied. While this is technically a viable system, it is easy to see that there is at least one major flaw. It is not uncommon for a developer to simply forget to check the patches directory.

Drush Patch File

Recently, we have begun to utilize Drush Patch File to improve this workflow. Drush Patch File endeavors to simply document and track what patches have been applied, and automatically reapply patches when a module has been updated.

With Drush Patch File, our legacy 'patches' folder still exists, but we replace its contents with a patches.make file similar to the one below:

; Required attributes api = 2 core = 7.x ; Core patches. ; D7 Backport: theme_table() should take an optional footer variable and produce <tfoot> ; @see https://www.drupal.org/node/1892654#comment-6956588 projects[drupal][patch][] = "https://www.drupal.org/files/Add_tfoot_support_to_theme_table-1892654-1.patch" ; Remove Html::resetSeenIds() call during form processing ; @see https://www.drupal.org/node/1831560#comment-7629461 projects[drupal][patch][] = "https://www.drupal.org/files/d7_form_html_id_1.patch" ; Contrib patches. ; devel ; Prefix tables in dpq() output ; @see https://www.drupal.org/node/2330035#comment-9105857 projects[devel][patch][] = "https://www.drupal.org/files/issues/2330035.1-dpq-prefix-tables.patch" ; Fix incrementing invalid property in _hive() ; @see https://www.drupal.org/node/2332361#comment-9118425 projects[devel][patch][] = "https://www.drupal.org/files/issues/2332361.1-hive-object-corruption.patch" ; entity ; entity_property_default_render_value_by_type() throws warnings on list properties ; @see https://www.drupal.org/node/2237141#comment-8669433 projects[entity][patch][] = "https://www.drupal.org/files/issues/2237141.1-list-warning.patch" Getting Started
  1. Clone the Drush Patch File repo into your project at 'sites/all/drush'.
  2. Create a patches.make file as detailed above, preferably outside of your docroot in a 'patches' folder.
  3. Point drush to your patches.make file by adding the following line in '/sites/all/drush/drushrc.php':

    $options['patch-file'] = '../patches/patches.make';

Drush Patch File's README provides detailed instructions on how to add new patches, check patch status, and apply all specified patches.

The Best Part

The best part of Drush Patch File, besides managing the tracking of all of your patches, is that it will reapply your patches automatically when you update a module!

drush up devel > The following indicates that the patches were successfully re-applied. Install location sites/all/modules/contrib/devel already exists. Do you want to overwrite it? (y/n): y Project devel (7.x-1.5) downloaded to sites/all/modules/contrib/devel. [success] devel patched with 2330035-1.patch. [ok]
Catégories: Elsewhere

Annertech: How to Integrate your Drupal Website with MS Dynamics CRM

mar, 04/08/2015 - 14:28
How to Integrate your Drupal Website with MS Dynamics CRM

Recently I wrote about integrating Salesforce CRM with Drupal. Continuing in the same series, the next CRM we’re going to look at is MS Dynamics from Microsoft.

Catégories: Elsewhere

Drupal Association News: Announcing a New Approach to Community at DrupalCon

mar, 04/08/2015 - 05:14

Drupal is a lot of things. It’s a platform, a CMS, software, and code. But here’s what Drupal is most of all: community.

That’s why DrupalCon has had community content baked in, first as a stand alone track across the entire event, then as a summit on the Monday of the Con. Now, we’re ready to double down on community starting at DrupalCon Barcelona. Together with Drupal’s Community Working Group, we’ve taken your feedback and devised a brand-new approach to community at the Cons.

You can skip the details and check out the new Communtiy Content at DrupalCon Barcelona.

What We Heard from You

We started with a survey to find out who’s participating in the Community content at DrupalCons and what you were hoping to achieve. You can review the full survey results, but here are a few key findings that we identified.

Meeting each other to build your network of support is the most important thing we can help facilitate. That’s followed by skills building, and then by actually getting specific work accomplished.

 

There is strong demand for a wide variety of skills training. We haven’t really provided this kind of content in a structured way for the community before, so we are excited to address it head on.

There was strong support for community content to be integrated into the main conference. We know that one reason community content moved to the summit format was poor attendance at community sessions at previous Cons, but we think this result means that we can integrate content back into the conference, but perhaps in a slightly different way.

What We’re Planning

Donna Benjamin, Adam Hill, and I met to discuss the survey results and get a plan together for Barcelona. Our goal was to build a comprehensive community program that provides a variety of ways to interact on community issues while also addressing the community concerns raised in the survey. In short, we’re proposing that community is integrated into every part of the Con. Here’s how it will work in Barcelona:

  • Community Keynote: We did it in Amsterdam, and it was such a success, we’re bringing it back in Barcelona. Thursday’s keynote is presented by the community, for the community. Mike Bell (mikebell_) will talk about mental health in the open source world and David Rozas (drozas) will talk about the phenomenon of contributing to a community.
  • Community Kickoff: On Monday, we will hold a community kickoff event for the week. We’ll begin with an introduction to all the community content at the Con, followed by exercises designed to help you meet the people that can help support you in your community work, whether you need help maintaining a long-standing camp or User Group, or if you’re new to the community and want to know where you can get involved. Then we’ll conduct breakouts to share knowledge around specific issues, and identify good topics for further discussion in the community Birds of a Feather sessions later in the week. We’ll end the day by joining the First Time Attendee social so that we can show the new folks what our community is all about.
  • Community BoFs:Tuesday through Thursday we will hold Birds of a Feather sessions to focus on community issues. Some (maybe all?) will be determined at the Monday kickoff. These sessions should bring people together around a common theme, like User Group leaders discussing best practices for organizing a DUG. All BoFs will be asked to identify a note taker who records key takeaways from the conversation that can be shared back out with the community.
  • Community Training: You asked for help building specific skills, so these sessions will be designed to help you learn specific takeaways and give you real tools you can use back in your community. Tentative topics include Camp Budgets and Financial Management, Conflict Resolution, Sponsor Recruitment and Management, Mentoring, and Public Speaking.
  • Community Sprints: After four days sharing what you know and learning new things, you’ll be itching to put your ideas to use. On Friday, sprint tables will be set aside to work on specific community issues that are raised throughout the week. Topics could include things like building a universal camp budget template or helping to find ways to integrate community contribution on Drupal.org profiles.

You can see that we’ve tried to bake community into the Con from start to finish and address all the different needs you identified. We hope this new format will make it easier for you to get the support you need to continue to do what you do best - make Drupal great!

Where Do I Sign Up?

To help organize our space and time, we’re asking you to RSVP for both the Community KickOff and the Community Trainings. All you need to do is head over to the Community Summit Page, find the content you're interested in, and add your name to the list.

In the meantime, if you have any questions or suggestions,

Flickr photo: Boris Baldinger

Catégories: Elsewhere

PreviousNext: Code Drop and PreviousNext merge Australia's leading Drupal 8 teams

mar, 04/08/2015 - 04:16

Two of Australia’s most prominent Drupal strategy, design and development companies, Code Drop and PreviousNext, have merged to form a single company with national reach. The merger will see both companies operate under the PreviousNext brand from August 4, with the Code Drop team remaining in their existing Perth offices and working across Western Australian and national projects.

Catégories: Elsewhere

OSTraining: Create a Juicebox Image Gallery in Drupal

mar, 04/08/2015 - 03:50
Last week, two different OSTraining members asked me about using the Juicebox image gallery with Drupal.

To be honest, I had never heard of Juicebox, but the members said that it looked great and worked well. After testing Juicebox, I agree. It's a good option for people who want a basic image gallery in Drupal.

Catégories: Elsewhere

PreviousNext: Overriding services in Drupal 8 - advanced cases

mar, 04/08/2015 - 01:12

Drupal 8 comes with a services based architecture allowing clean dependency injection, separation of concerns and another way to modify how Drupal works without hacking core

You've probably heard that Drupal 8 lets you swap out a core service for your own implementation, hey, I even said it myself here and here, but how do you achieve that?

Read on to find out how to manipulate Drupal 8 services at run-time and how this compares to other popular PHP Frameworks like Laravel, Silex and Symfony

Catégories: Elsewhere

Gizra.com: Visual Regression Tutorials

lun, 03/08/2015 - 23:00
Complex dynamic page

A well known DrupalCon fact is that the action mostly takes place in the hallways and social gatherings. The logic is that the sessions are recorded, and the rest isn't.

On DrupalCon L.A. I was spending most of my time in the hallways stalking people to show them the newly born Shoov and ask for their feedback. One of those people was my good friend Mike Anello, which later expressed his feeling about Shoov in this fun DrupalEasy podcast.

Few months later, with the next DrupalCon already around the corner and Shoov maturing every day, I've contacted him to get his feedback on what we have so far, and I got this:

I think one that could help me and other developers is almost something like a glossary. I’ve heard of many of the technologies in your visual monitoring “stack”, but not entirely clear on what the purpose of each one is (Yeoman, WebdriverCSS, mocha, etc… - Behat I know!

Let's start from the end, because those three words made an impact on me - "Behat I know".

As a reader of this post you are probably familiar with Behat or at least know what functional testing frameworks are.

Do you remember that time in the past you didn't?
Do you remember that time in the past where functional testing was just a nice to have for you and not the life saver it is now days?

Continue reading…

Catégories: Elsewhere

OSTraining: "No front page content has been created yet" in Drupal

lun, 03/08/2015 - 19:44

When you first load up a new Drupal site, you will a screen like the one below.

On the front page of your site will be this message: "No front page content has been created yet".

Catégories: Elsewhere

DrupalCon News: Training Spotlight: Drupal 8 Theming

lun, 03/08/2015 - 19:29

With the Drupal 8 release just around the corner, now is the time to learn about the major changes it will bring for themers. For example, TWIG will be the default theme engine and thus you need to be familiar with its templating syntax. Other new hot features worth exploring are YAML config files, breakpoints, library management etc. Join this class and learn all you need to know to create your own theme in Drupal 8.

Catégories: Elsewhere

Drupal core announcements: No Drupal 6 or Drupal 7 core release on Wednesday, August 5

lun, 03/08/2015 - 16:59

The monthly Drupal core bug fix/feature release window is scheduled for this Wednesday. However, there have not been enough changes to the development version since the last bug fix/feature release to warrant a new release, so there will be no Drupal core release on that date. A Drupal 7 bug fix/feature release during the September window is likely instead.

Upcoming release windows include:

  • Wednesday, August 19 (security release window)
  • Wednesday, September 2 (bug fix/feature release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Catégories: Elsewhere

EchoDitto Tech Blog: Drupal 8? Drupal, Wait

lun, 03/08/2015 - 16:16

If you’ve been following the Drupal community, you’re probably well aware of the impending arrival of Drupal 8. And if you’ve been following the Drupal community closely, you’ve probably been anxiously awaiting D8 since late 2012.

Well, we’re happy to say that the wait is over...sort of. D8 was technically released (in initial beta form) in October 2014. And while a lot of us here at Echo have gotten our hands on it and taken it out for a few spins, don’t expect to see any D8 sites flying out our doors anytime soon.

What’s the Hold Up?

The biggest problem is simply that Drupal 8 isn’t ready. Even Dries Buytaert, the creator of Drupal, said this year at DrupalCon Los Angeles that he doesn’t recommend using Drupal 8 for production websites yet. That’s not to say you couldn’t make a website using D8 if you really wanted to, but it would be a time-consuming and risky proposition: your developers would have to account for the steady stream of changes being made to D8 as the community addresses remaining bugs, and these core updates could trigger nasty bugs that could take down your whole site.

Trying to bring an old site into D8 would be harder still—the upgrade path isn’t fully supported, meaning you wouldn’t be able to move cleanly from a D6 or 7 site straight to D8. In addition, as of July 20, there are still a dozen critical D8 bugs left published on Drupal.org—down from the 28 that remained when Dries gave his keynote speech but still not the zero required for an official release candidate.

So when will it be ready? “The reality is, it’s done when it’s done,” says Dries. He and the other contributors’ stretch goal is to have the first official release available by the time Drupalcon Barcelona rolls around in mid-September, but in all likelihood, it’ll be closer to early 2016.

From what we’ve seen in our testing here at Echo, we have to say: D8 looks pretty sweet. Built-in Views integration, Twig support, and improved admin tools are among the many features we and a lot of Drupal developers have been awaiting for a long time. We’re hoping to start building our first D8 sites between late this year and early next year, but like Dries said—“It’s ready when it’s ready.”

Tags: drupaldrupal 8development
Catégories: Elsewhere

OpenConcept: An overview of software testing

lun, 03/08/2015 - 15:31

"Software testing" is a term used to refer to a variety of methods, tools, and practices for verifying that a software application works, at many different levels.

All of us in the web development industry do some sort of software testing (even if the testing we do is manual and ad hoc, e.g.: refreshing a webpage after making a change to ensure the code you just wrote works). In this blog post, I will attempt to discuss why you might want to move away from ad hoc testing to more-formal testing, try to dispel some myths about formal testing, and give a high-level overview of the different ways that software can be tested, and the different levels of software testing that exist.

First: a disclaimer — I am not a software testing expert, and to a large extent, I wrote this to help wrap my head around software testing. Also, trying to fit complex, multi-faceted things into neat boxes is difficult (and/or controversial), so be aware that others might classify testing differently. If you find out mistakes or agree/disagree with my categorizations, please let me know in the comments below.

This blog post assumes that:

  • you work in the software development industry, and,
  • you've done manual, ad hoc tests at some point (and have an idea of why they are important).
What do you mean by formal tests?

This blog article considers "formal" tests to be tests which are recorded in some way so that other people (i.e.: not the original developer) or software can run them at any time.

Why test formally?

Software testing is an important tool with benefits such as:

  • a "safety net" to ensure each subsequent change to a program doesn't cause a regression or loss-of-functionality,
  • a "sanity check" to ensure that the code written meets the expectations / requirements of the client and your peers,
  • a way to ensure that your code is not too tightly coupled to a particular set of assumptions or use-case (this evolves naturally as you learn to write testable code),
  • a collaboration tool to ensure that someone else's work doesn't inadvertently break your work and vice-versa,
  • a portability check to ensure that code works outside of your specific environment's assumptions, and even,
  • a way to ensure that time is not wasted over-engineering solutions to problems.

Depending on the nature of your work and clients, manual ad hoc testing might be sufficient for a while.

However, as projects, development time, product lifecycles, and/or consequences-of-failure grow in size, complexity, and budget, the benefits listed above become increasingly important to limit the risk of client dissatisfaction, going overbudget, getting stuck in development/bug-fixing hell, and/or the risk of producing software that requires a high level of skilled maintenance to continue functioning.

Formalizing these tests (even manual tests) by recording them in some way allows you to run them the same way every time you run them, ensuring you don't forget something important. It also allows your co-workers to run them if you're busy, or computers to run them if they're automated. And, formal manual test cases can usually be converted to automated tests with little effort.

Myths of formal testing
Myth: Writing formal software tests isn't worth the cost.
While it certainly takes a while for new testers to get used to how testing works, and it is possible to write too many tests, even a little bit of testing can greatly reduce development time later in the development cycle, both before the product is launched, and during maintenance later on. Acceptance and refinement tests specifically (see below) can also help to give all involved parties a sense of what needs to be focused on, reducing project management time, wasted development time, and the risk of producing a product that clients (or in the case of a website, the general public) doesn't want or cannot use.
Myth: Formal software tests must be written only by software developers.
While developers must write certain tests, and are typically capable of writing most (if not all) types of tests, there are certain types of software tests which are better written by product owners, clients, testers, developers, and designers.
Myth: Most tests should be written after the system is (mostly) functionally-complete.
While the Waterfall software development model states this, the reality is that the earlier you start testing, the earlier you find and correct bugs, missing functionality, architecture problems, and usability issues.
A brief note about test-driven development (TDD)

A powerful way to write software is using Test-Driven Development (TDD). Simply put, TDD is the practice of writing tests first (so your intents are clearly stated), then writing the code to meet the requirements of the test. Test-driven development is applicable to all areas of software testing, except, perhaps, certain types of refinement tests.

Test-driven development has two distinct advantages:

  1. it ensures that everything you write from the point when you start using TDD is well-tested ("has good test coverage"), and,
  2. if you follow the TDD principle to stop developing when the tests pass, you can ensure that you don't waste time over-engineering solutions to problems.

I highly recommend reading Test-Driven Development By Example by Kent Beck (Addison-Wesley, 2003).

Classifying tests

All types of software tests can be classified as white-box, black-box, or grey-box:

White-box tests
Clear-box tests
Tests written to test the internal structure of something, as opposed to it's functionality. Named because you typically look at the code you're testing, and write your tests to target it.
Black-box tests
Tests written to test the functionality of something, as opposed to it's internal structure. Named because you typically (pretend that) you know nothing about the implementation of something, and write your tests to do what you'd expect it to do.
Grey-box tests
A combination of white- and black-box testing, used to test for improper structure or usage defects.
Levels of software testing

I group software testing into five main levels,

  1. Unit tests,
  2. Integration tests,
  3. Acceptance tests,
  4. Refinement tests, and,
  5. System tests.

Generally, the number of tests decrease; but the coverage scope, run-time, effort and cost of the tests increase as you go down the list (i.e.: in a well tested system, there are many unit-tests, each covering a small scope (e.g.: a single function), but few system tests, each covering a wide scope (e.g.: many objects, functions, and subsystems working together as-intended)).

To help you keep track of all these things, I've put together a software testing cheat sheet for you to download. The cheatsheet's source code is on Github, so feel free to improve it!

Unit tests

Unit tests are typically white-box tests to cover edge-cases and code branches (code paths) in a limited scope, typically on a per-function level. Each function typically has one or more unit tests that focus on ensuring each code path functions in the expected manner. Small changes to the code under test typically require changes to the unit tests to incorporate the new changes and ensure new code paths are covered.

Unit tests are typically short and quickly-written by the software developer who is writing the code under test, using carefully-chosen test parameters (typically edge-cases); by checking pre- and post-conditions, state-changes, and output; and by mocking dependencies to ensure that the test only covers the function under test.

Ideally, unit tests are written before the function(s) they test (i.e.: following Test Driven Development principles). If writing and performing unit tests is required for new work, your last chance to do so is before committing or submitting your code for code review.

Key technologies for unit testing are:

  • phpUnit, RSpec, Jasmine, QUnit, Unit.js, etc. (sometimes collectively referred to as xUnit because many follow a naming pattern of <language abbreviation>Unit).
    • Note that SimpleTest in Drupal 6 contrib and in Drupal 7 core can be used to do unit tests, but it's not very good at it, so it's been replaced with phpUnit in Drupal 8.
  • Mock objects (e.g.: Hamcrest).

... note that many of the key technologies can also be used for integration and acceptance (behaviour) testing.

Other names for unit tests are:

  • component tests

Some books on unit tests and mock objects that I've read and recommend are:

Integration tests

Integration tests are typically grey-box tests to cover interactions between objects and interfaces, on a limited scope, typically on a per-object or per-subsystem level. Each object and subsystem typically has one or more integration tests that focus on ensuring the object/subsystem interacts with it's dependencies in the expected manner. Small changes to the code under test might require changes to the integration tests, especially when they change the way an object/subsystem interacts with other objects/subsystems.

Integration tests are typically medium-length and quickly-written by the software developer who is writing the object/subsystem code, by checking success and failure states, how they interact with other components (through mock objects), what they accept as input, what they produce as outputs. Mocking dependencies, shared resources and inter-process-communication is common practice at this level.

Ideally, integration tests are written before the object(s) they test (i.e.: following TDD principles). If writing and performing integration tests is required for new work, your last chance to do so is before committing or submitting your code for code review.

Key technologies for integration testing are:

... again, because unit tests and integration tests are so similar, they share a lot of the same technologies.

Other names for integration tests are:

  • integration & testing (I&T)

Some books on unit tests and mock objects that I've read and recommend are:

Acceptance tests

Acceptance tests are typically black-box tests to cover how a user moves through a system on a broader scope, typically at the user-interface level. Each user-interface display typically has a number of acceptance tests that focus on ensuring the user can complete a certain set of tasks using that display, that the display functions correctly, and that it meets the client's requirements. Small changes to the code under test only require changes to the acceptance tests if the changes affect the user interface.

Acceptance tests are typically short and written by the product owner, client, tester, or in some cases, the developer, by looking at the user story / ticket and outlining the steps the user must take to complete the requested functionality.

Ideally, acceptance tests are written by the client, or product owner before the UI is developed and any work is done. If writing and performing acceptance tests is required for new work, your last chance to do so is before committing or submitting your code for code review.

Ideally, parameters for accessibility testing (i.e.: level of conformance) and browser testing (i.e.: list of supported browsers) should be defined by the client before any work is done; and the latest these should be defined is before any work is started.

Key technologies for acceptance testing are:

  • Manual tests (using manual test cases).
  • The Gherkin domain-specific language.
    • Tests written in Gherkin are turned into mouse clicks, keystrokes, etc. by interpreters (e.g.: Behat, Cucumber, SpecFlow).
      • These interpreters forward these mouse clicks, keystrokes, etc. through controllers (e.g.: Mink, Webdriver, CasperJS) to browsers.
        • Controllers like Mink or Webdriver then control:
    • Behavioural output from browsers is usually forwarded back to the Gherkin interpreters for analysis.
    • Visual output from browsers can be forwarded to visual regression tools (e.g.: the Galen framework).
  • SimpleTest in Drupal 6 contrib and in Drupal 7 core.
  • Visual difference tools (e.g.: Shoov).
  • Accessibility testing, both automated (e.g.: Quail) and manual (e.g.: VoiceOver, JAWS).
  • Browser testing (i.e.: ensuring it works in each browser), either automatically (typically performed with the Gherkin stack above), or manually (using a manual test case with local browsers, browsers in virtual machines, or browsers in the cloud).

Other names for acceptance tests are:

  • conformance tests
  • behaviour tests
  • functional tests
  • User Acceptance Tests (UAT)
  • validation tests
Refinement tests

Refinement tests are usually black-box tests to determine if a proposed UI is:

  • useful (does the system do what the user wants to do)
  • usable (can the user figure out how to get their tasks done)
  • aesthetically pleasing (does the UI look good)
  • identifiable (is the purpose of the system clear)
  • inspirational (does the system inspire the users to use it), and,
  • valuable (does the user value the system and it's purpose)

... on a broad scope, at the user-interface level. Each design stage / refinement typically undergoes a series of tests to ensure the design provides a good end-user experience. Changes to the code under test don't normally require changes to the refinement tests unless a desired UI element is deemed too costly to complete.

Refinement tests are typically written by a designer or UX expert by presenting a UI design to users and gathering data on how they experience it, and may be repeated as the design progresses. Beginning refinement testing before any real (non-prototype) code is implemented often reduces the number of design / UI changes later on in the development cycle, as the biggest usability problems can be identified as early as possible.

Ideally, refinement tests are written before the UI is developed and any work is done. If writing and performing refinement tests is required for new work, your last chance to do so is before committing or submitting your code for code review.

Key technologies for refinement testing are:

  • Visual difference tools (e.g.: Shoov).
  • A/B testing frameworks (e.g.: Acquia Lift).
  • Accessibility testing, both automated (e.g.: Quail) and manual (e.g.: VoiceOver, JAWS).
  • Talking to actual users.
  • Observing how users use the system.

Other names for refinement tests are:

  • UX tests
  • Usability tests
  • Business-value tests
  • Return On Investment (ROI) tests
  • End-user tests
  • Field tests

Some books on refinement tests that I've read and recommend are:

System testing

System tests are typically black-box tests to cover the system as a whole and catch regressions, on an extremely broad scope, at the user-interface level. The system usually has a number of system tests, each of which may focus on an important aspect of the system. Small changes to the code under test don't normally require changes to the system tests.

System tests are typically written by the tester, developer, and product owner, to by writing regression tests, setting performance acceptability thresholds, stress-testing the system, ensuring the system is compatible with the systems it's designed to work with (e.g.: where it will be deployed), and whether the system can recover from unexpected, serious problems outside of it's control (recovery tests).

Ideally, system tests are written or their parameters are chosen before any development work is done. If writing and performing system tests is required for new work, your last chance to do this is after integrating code together, usually before a demo to the client or a beta test.

One thing to note about system testing is that the results of the tests aren't always a strict pass/fail, and therefore aren't always actionable. In this case, trends are more important: you should expect software that just got a whole bunch of new features to be a bit slower; but if it's a lot slower, then you should probably examine the new code and schedule some time to refactor.

Key technologies for system testing are:

  • Analysis tools (e.g.: New Relic)
  • Load-testing tools (e.g.: Siege)
  • Manual tests

Other names for system tests are:

  • End-user tests
  • Field tests
  • Regression tests
  • Performance tests
  • Failure tests
Bonus: Smoke tests

Smoke tests are extremely-small, preliminary, typically ad-hoc tests to reveal major defects that would typically preclude someone's ability to run other tests. For example:

  • code that does not compile because of a syntax error prevents all tests from being run, therefore, syntax linters could be considered a type of smoke test;
  • if a file added in the latest deployment does not exist after the deployment, or the file is empty (and it isn't supposed to be), that's usually a good indication that a deployment failed.

Rumor has it that the term "smoke tests" is a calque from the discipline of electrical engineering, where, if you plug something in and it starts to smoke, that typically indicates that something is wrong and would prevent further testing.

Other names for smoke tests are:

  • confidence tests
  • sanity tests
  • intake tests
In conclusion

Hopefully, this blog post will help you to understand some of the terminology that surrounds software testing.

Special thanks to my friend Anand Sharma, who is just as passionate about software quality, and has been a big help and influence in helping me learn software testing. He also reviewed the software testing cheat sheet for me. Also, thanks to Patrick Connelly for the great tools he built and conversations we've had about continuous integration and software quality in general.

Some books on this subject that I've read and strongly recommend are:

If you're looking to implement formal software testing at your organization, don't be discouraged by the fact that it takes a while to learn how to write good tests: it's worth the investment.

Next week, I'll write a bit about automated testing, continuous integration, and continuous delivery.

AttachmentSize Software Testing Cheat Sheet (updated 2015-07-31)120.53 KB Topic: 
Catégories: Elsewhere

Web Wash: How to Display Icons in Drupal using Icon API

lun, 03/08/2015 - 13:15

Good use of icons on a website can really lift its overall design. Of course, you can't just slap them on and expect a site to look brilliant. It's all about choosing the right type of icons to match the design.

Once your designer has chosen a font library like Font Awesome, or made their own, what is the best way of displaying them in Drupal? The quick and simple way is to get the designer to style them using CSS but this is not flexible.

What if an editor wants to choose which icon is displayed in a menu? If you've added them to the menu manually via CSS then the editor won't have the ability to change the icon in the future.

The Icon API module integrates common icon bundles like Font Awesome, Bootstrap and more within Drupal. The module offers integration with a suite of sub-modules. For example, if you want to add icons to menus then install the icon_menu module.

In this tutorial, we'll configure Icon API to allow an editor to add icons to menus and directly into content. We'll do this using the Font Awesome icon bundle.

Catégories: Elsewhere

OSTraining: New Video Class: Speeding Up Your Drupal Site

lun, 03/08/2015 - 10:04

Drupal is a fantastic CMS, but it can be slow if the site is complex or on a slow server. With Google's focus on site speed, this is a very important issue.

In this week's new class, "Speeding Up Your Drupal Site", Robert helps us get the most out of Drupal's power without sacrificing performance.

Robert explains the caching power of Drupal, and introduces you to several great modules to help speed up your site.

Catégories: Elsewhere

Web Omelette: Write your own Views Bulk Operations actions in Drupal 7

lun, 03/08/2015 - 09:05

Views Bulk Operations (VBO) is a powerful module that leverages Views to allow site administrators to perform bulk operations on multiple entities at once. It does so efficiently by processing the items in batches over multiple requests to avoid timeouts.

Installing the module will already provide you with a host of various actions you can perform in bulk on various entities. You can publish 1000 nodes at once, delete them or even change their author. And these are just a few examples of what you can do.

In this article we are going to look at programatically creating our own action that we can trigger with VBO to affect multiple node entities. Sometimes you need to write your own because the use case does not quite fit in the extensive list of actions the module provides.

For our example, let's assume we have an entity reference field called field_users on both the article and basic page content types. This field can reference whatever user it wants. And the requirement is to be able to bulk update the value of this field on a bunch of nodes of both these node types at once.

Out of the box, VBO provides us with an action to change the value of a field but this doesn't help us in this case. When adding a value to this field via VBO, we are presented with as many instances of the field as different node types are in the selection. And this is not ideal if we want to scale the functionality to more than one content type. What we want is to select a number of nodes and then only once provide a value to this field. So let's see how we can define a custom VBO action for this use case.

The action

To define a new action we need to implement hook_action_info():

/** * Implements hook_action_info(). */ function my_module_action_info() { return array( 'my_module_my_custom_action' => array( 'type' => 'entity', 'label' => t('Add a user to Users field'), 'behavior' => array('changes_property'), 'configurable' => TRUE, 'vbo_configurable' => FALSE, 'triggers' => array('any'), ), ); }

With this hook implementation we are defining our own action called my_module_my_custom_action which is available to be triggered on all entity types (because we specified entity for the type) and it acts as a property changer. It is configurable using the default Action API but we don't need any kind of VBO specific configuration. For more information on all the values that you can pass here, feel free to consult the documentation page for VBO.

Next, it's time to create the configuration form for this action, namely the form that will be presented to us to select the user we want to add to the field_users reference field:

function my_module_my_custom_action_form() { $form = array(); $form['user'] = array( '#type' => 'textfield', '#title' => t('User'), '#maxlength' => 60, '#autocomplete_path' => 'user/autocomplete', '#weight' => -1, ); return $form; }

The function name takes from the machine name of the action suffixed by _form and is responsible for creating and returning a form array. All we need is one field which uses the core user/autocomplete path to load users via Ajax. Simple enough.

So now after we make a bulk selection and choose our action, we'll be prompted with this form to choose the user we want to add to the reference field. It follows to couple it with a submit handler that will save the value into the context of the operation:

function my_module_my_custom_action_submit($form, &$form_state) { $uid = db_query('SELECT uid from {users} WHERE name = :name', array(':name' => $form_state['values']['user']))->fetchField(); return array( 'uid' => $uid, ); }

The naming of this function is similar to the previous one except for the suffix being _submit this time around. In it, we load from the database the uid of the user that was referenced in the form field by name and return that inside an array. The latter will then be merged into the $context variable available in the next step.

So it's now time to write the final function which represents this step by adding the selected user to the existing ones in that field across all the selected nodes, regardless of their type:

function my_module_my_custom_action(&$entity, $context) { if (!isset($entity->field_users)) { return; } if (!isset($context['uid'])) { return; } if (!empty($entity->field_users)) { foreach ($entity->field_users[LANGUAGE_NONE] as $ref) { if ($ref['target_id'] === $context['uid']) { return; } } } $user = array( 'target_id' => $context['uid'], ); if (!empty($entity->field_users)) { $entity->field_users[LANGUAGE_NONE][] = $user; return; } $entity->field_users[LANGUAGE_NONE] = array($user); }

The name of this function is exactly the same as the machine name of the action, the reason for which we prefixed the latter with the module name. As arguments, this function gets the entity object that is being changed (by reference) and the context of the operation.

We start by returning early if the current entity doesn't have our field_users field or if by any chance the uid key is not available inside $context. Then we loop through all the values of the field and return if the selected uid already exists (we don't want to add it twice). And last, we add the selected uid to the list of existing users in the field by taking into account the possibilities that the field can be empty or it can already contain values. After passing through this action, VBO will automatically save the node with the changes for us.

And that is pretty much it. Clearing the cache will make the new action available in the VBO configuration of your view. Adding it will then allow you to select as many nodes as you want, specify a user via the autocomplete field and have that user be added to the field_users field of all those nodes. And the cool thing is that you can select any node you want: if the field doesn't exist on that content type, it will just be skipped gracefully because we are checking for this inside the action logic.

Hope this helps.

In Drupal var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Catégories: Elsewhere

Damien McKenna: My Drupal contrib plans for August, updated

lun, 03/08/2015 - 03:03

A few weeks ago I posted my plans for my personal Drupal contributions for the next month-or-so. I wanted to give a minor update on what I'd managed to achieve so far.

Tags: 
Catégories: Elsewhere

Pages