The BDD PHP framework Behat, allows you to test your PHP applications using human-readable sentences to write features and scenarios about how your applications should behave in order to test out its functionality. We can then run these tests to see if our application is behaving as expected. Let’s spend about 15 minutes quickly going over Behat’s installation process and learn how we can test our PHP applications behavior using the basics.

Installation

To begin testing with Behat, we just need to install it on our local development machine. I’ll be using Composer, but you can take a look at a the documentation for additional installation methods.

Within your PHP application (I have a blank PHP app named phpbehat created in advance) create a composer.json file with the following code to load in Behat:

{
    	"require": {
    		"behat/behat": "2.4.*@stable"
    	},
    	"minimum-stability": "dev",
    	"config": {
    		"bin-dir": "bin/"
    	}
    }
    

In your terminal we can install it using the following command:

composer update

We should now be able to run the bin/behat command to work with Behat.

Creating Features

We always begin by creating a new feature. A feature is something that we can use to describe a feature of our application and then implement it to get the test to pass.

A feature, at its simplest, consists of:

• Human-readable, plain text.
• Uses a .feature extension.
• Contains the feature’s benefit, role, and the feature itself.
• May hold a list of scenarios.

Now I can’t show you how to test all possible features for an application, as that would take far too long. But what I can do is show you how to go about writing a basic feature and you can adapt this code to make it work for your specific application.

Testing the Phpadder Class

To avoid complicating the learning process, let’s create a very simple Phpadder.php file which contains a couple methods that we can use to add two numbers together and display their sum.

class Phpadder {
    
    	private $a;
    	private $b;
    	public $sum;
    
    	public function __construct($a, $b) {
    		$this->a = $a;
    		$this->b = $b;
    	}
    
    	public function add() {
    		$this->sum = $this->a + $this->b;
    	}
    
    	public function display() {
    		return $this->sum;
    	}
    }
    

This creates a new class named Phpadder. We have a few properties to hold the first ($a) and second ($b) numbers to be added, as well as a $sum property to hold the values’s sum.

Next, we have our constructor which initializes our properties. Then we have an add method to add the two numbers together and finally a display method to display the sum of the two numbers.

Adder Feature

Let’s now test this Phpadder class. Create a new .feature file along with the following code:

# features/phpadder.feature
    Feature: adder
    	In order to display the sum of two numbers
    	As anybody
    	I need to provide two numbers
    

We start out by giving our feature a name of adder. Then we specify, on three lines, the feature’s benefit, role, and finally the feature itself. It should be fairly self explanatory.

Now that we have our feature, let’s start writing our scenarios.

Creating Scenarios

Anytime we create a feature we can define scenarios that describe how that feature behaves given certain conditions. Scenario’s follow the same basic layout consisting of the scenario’s description, a context, an event, and an outcome.

Let’s create a scenario to test out our Phpadder application:

Scenario: Display the sum of two provided numbers
    	Given I have the number 50 and the number 25
    	When I add them together
    	Then I should get 75
    

We begin with our scenario description, we then list out that we start with the two numbers of 50 and 25 and when they are added together it should display the sum of 75.

You can also have multiple contexts, events, and outcomes as well using the following keywords: And and But. Here’s a modified example of the previous scenario where we’ll use And:

Scenario: Display the sum of two provided numbers
    	Given I have the number 50 and the number 25
    	And I have a third number of 25
    	When I add them together
    	Then I should get 100
    

Creating Step Definitions

A step is nothing more than a PHP function which is made up of a keyword, a regular expression, and a callback function. Each statement within your scenario will be matched to a step. These steps define what should happen given one of your statements are called within a scenario. You store all of your steps within the features/bootstrap/FeatureContext.php file.

The “Given” Step

In our FeatureContext.php file (you may need to create this), we need to write a step for each of our statements, using its name as the function name. We’ll start with the "Given I have the number" statement:

# features/bootstrap/FeaturesContext.php
    
    require("Phpadder.php");
    
    use Behat\Behat\Context\BehatContext, 
    	Behat\Behat\Exception\PendingException;
    
    use Behat\Gherkin\Node\PyStringNode,
    	Behat\Gherkin\Node\TableNode;
    	
    class FeatureContext extends BehatContext {
    
    	private $Adder;
    	
    	/**
    	 * @Given /^I have the number (\d+) and the number (\d+)$/
    	 */
    	public function iHaveTheNumberAndTheNumber($a, $b) {
    		$this->Adder = new Phpadder($a, $b);
    	}
    

First, we create a new PHP file, require in our Phpadder.php file (the file that we’re testing), and then we use a few Behat classes with use statements, right after.

Next, we create our FeatureContext class and have it extend the BehatContext class.

Our class has only one property, $Adder, which will hold a Phpadder object.

Finally, we create a method for our first step using the same name as the statement. Our step has a regular expression, found within the method’s comment. This regular expression is used to match the step to a scenario statement. Within this method we simply assign a new Phpadder object to our $this->Adder property so that the rest of our methods have access to the same Phpadder object.

Now, you’ve probably noticed the @Given keyword within your function’s comment, this is actually an annotation so that the different types of steps can be identified. You can use @Given, @When, and @Then.

Now we just need to write the last two steps.

The “When” Step

/**
     * @When /^I add them together$/
     */
    public function iAddThemTogether() {
    	$this->Adder->add();
    }
    

This step simply uses our $this->Adder object’s add method to add the two numbers together.

The “Then” Step

/** 
     * @Then /^I should get (\d+)$/ 
     */
    public function iShouldGet($sum) {
    	if ($this->Adder->sum != $sum) {
    		throw new Exception("Actual sum: ".$this->Adder->sum);
    	}
    	$this->Adder->display();
    }
    

This step starts off by checking if the actual sum (retrieved using our $this->Adder object and its sum property) is not equal to the expected sum. If this evaluates to true that means we need to have Behat show a failure. To do so, we’ll just throw a new exception displaying the actual sum so we can compare. Otherwise, we call our display method.

Time to run the tests.

Running the Tests

Now that we have our features, scenarios, and steps laid out, let’s run our tests using the following command:

bin/behat
    

You should see the following success messages inside of your terminal:

You can ensure that your tests are running correctly, by simply breaking something in your Phpadder.php file so that it doesn’t run quite the same way your test expects it to. For example, if we change the add method to instead use subtraction, like so:

public function add() {
    	$this->sum = $this->a - $this->b;
    }
    

And then we rerun our tests: bin/behat. You can see in our terminal, we now have a failing test, because it’s no longer adding our numbers but subtracting them:

Conclusion

In conclusion, you can follow a small four step process for testing your PHP apps using Behat:

1. Define a Feature
2. Define a Scenario
3. Define Step Definitions
4. Run the tests using bin/behat

So, with just that small amount of code, we should now have a basic understanding of how to work with Behat to test our PHP applications. For more information about working with Behat please checkout their documentation.

NEWS RELEASE –December 2013
Contact:
Alexandra Gold
bwtech@UMBC Research and Technology Park
443.543.5047
alexandragold@umbc.edu

Three new companies and one expanding company move into bwtech@UMBC’s newest space

Baltimore, MD (December 23, 2013) – bwtech@UMBC is pleased to announce the arrival of the first four companies to its newest space, the CyberHive. ParaTools, Inc., Integrata Security, LLC, and CloudCover, Ltd. have moved into the recently completed space down the hall from the Cyber Incubator located at 5520 Research Park Drive, Baltimore, Maryland. The fourth new CyberHive tenant is current Cyber Incubator company Fearless Solutions, LLC, who has expanded into the new CyberHive office.

The CyberHive was developed to accommodate bwtech@UMBC’s growing incubator program, which continues to accept, nurture, and graduate companies on a regular basis. The first company to join the CyberHive was ParaTools, Inc., www.paratools.com, devoted to the development and application of tools for parallel computing systems, with specific expertise in high performance computing and performance analysis. Most notable in their parallel tool development portfolio is the TAU Performance System® in use at research laboratories across the United States.

The second, Integrata Security, LLC, www.integratasecurity.com, has developed the world's most advanced and effective system for protecting wireless networks.  With technology exclusively licensed from the Department of Defense, Integrata's solution allows enterprises and governments to finally take advantage of safe wireless networking and safely manage the bring-your-own-device (BYOD) movement.

The third new company to call CyberHive home is CloudCover, Ltd. Headquartered in Burnsville, MN, CloudCover, www.cloudcover.net, is a cyber-risk insurance entity uniquely aligned with cyber security technology focused on underwriting and insuring data security and privacy within online networks. The company’s core solution, known as CloudCover Data Insurance™(CDI), represents a new category of insurance providing continuous data risk governance, as well as active risk transfer protection collectively known as the CloudCover Protocol™.

“CloudCover is excited and feels honored to participate in one of the most advanced, if not the best cyber-technology development incubator, whose primary focus is protecting our country's cyber security and privacy,” said Stephen Cardot, President of CloudCover.

Fearless Solutions joined the Cyber Incubator in June 2010 with one employee, the founder, President, and UMBC graduate, Delali Dzirasa. Since its inception, the company has grown to twelve employees and has won several large contracts in the federal space. “Despite government shutdowns and sequestration, we still managed to grow in the Cyber Incubator and that has been the direct result of our partnership with bwtech@UMBC.  We're excited to expand into the CyberHive and further benefit from the resources that the incubator has to offer,” said Dzirasa.

Fearless Solutions, LLC, www.fearlesssolutions.com, is a minority-owned business that serves a variety of federal, state and local government clients as well as commercial sector clients. The company's core competencies include: visualization, rapid prototyping / proof of concept, software engineering / web application development, development infrastructure setup, project and program management, and equipment procurement.

"We are very excited that ParaTools, Integrata and CloudCover have joined the CyberHive here at the Cyber Incubator@bwtech, and that Fearless Solutions is expanding into this new space as well,” said Jennifer Reynolds, the Director of Venture Creation at bwtech@UMBC. “We are always looking for new, innovative cyber businesses and technologies to add to bwtech’s already large cyber security community.  We are eager to support each of these companies and look forward to their growth and anticipated positive impact on economic development for the region."

About CyberHive: The CyberHive, located at the Cyber Incubator at bwtech@UMBC, offers a unique business development co-working environment for cyber companies seeking opportunities with the government, military and commercial sectors. CyberHive participants enjoy business support services from bwtech@UMBC’s experienced entrepreneurial services team, robust and redundant data connectivity, shared reception areas, private phone booths, coffee lounge, and conference rooms. "Hive" participants also have the opportunity to regularly interact with bwtech@UMBC's cyber security community, which includes over 45 companies and agencies at bwtech@UMBC, as well as UMBC students, faculty and other resources

About bwtech@UMBC: bwtech@UMBC, www.bwtechumbc.com, is a 71-acre research and technology community at the University of Maryland, Baltimore County (UMBC). With over 500,000 square feet of office and laboratory space, it is home to nearly 120 technology and life science companies at all stages of development. bwtech@UMBC offers collaboration with university faculty and students and enjoys a strategic and convenient location, close to downtown Baltimore, BWI Thurgood Marshall Airport, and Washington, D.C. Its annual economic impact on the state is estimated to be over $300 million.

·        TOEFL Board Grants

·        TOEFL International Speaker Grants

·        Library and Resource Center Award

·        TOEFL Outstanding Young Scholar Award

The following is a guest post by Philip Walton (@philwalton). Philip recently went through a slew of interviews for front-end jobs at tech companies in the Bay Area and found them to be not what he expected.

A few months ago I started casually looking for front-end gigs in the San Francisco Bay Area. I liked my current job, but I felt I was outgrowing the tech scene in my town. I wanted to leave my small pond and see how I'd fare in a big one, with some of the best developers in the world.

When I started looking I knew I wanted to work at a place where I wouldn't be the expert, so I only applied to big name companies. The whole experience ended up being quite valuable, and through it I got a chance to meet some of my heroes and visit the offices of some of my favorite companies.

But it wasn't all good. In fact, after looking back on the process I can't help but feel like there is something fundamentally wrong with the way tech companies interview their front-end candidates.

Before continuing, I want to offer this disclaimer. Parts of this article are going to be critical, so I think it would be best to keep the names of these companies anonymous. After all, who they are is not relevant to my overriding point.

The only details I will share is that I applied to and had phone interviews with six companies, four of which invited me to interview on-site. In total I had 23 different interviews, all of them technical.

The other thing worth mentioning is that these were all well-known companies. Companies I'm 100% sure you've all heard of, and I mention that not to brag, but to suggest that since they're the ones who set the bar where it is, the experiences I had were probably pretty close to the norm.

My Experience

Overall, my experience was quite good. Some of these companies have a reputation for their excruciating interviews, but what I went through was not nearly as bad as the stories I'd heard. Everyone was nice, everyone was professional, and if I didn't know the answer to something, I never felt belittled. Most of the time it just seemed like a simple conversation about technology between two people discussing the best way to solve a problem.

But there was something obvious missing: front-end specific questions!

Now, I'm no interviewing expert. And I'm sure most hiring managers would disagree over how to best measure the effectiveness of any particular set of interview questions. But one thing I'm sure everyone can agree upon is that the questions you ask should be questions that will be best answered by the most qualified people for the job.

To put that another way, if a talented computer science grad, fresh out of college, with almost no front-end experience can outshine a great front-end engineer in your interview, you're probably asking the wrong questions.

This basically sums up my criticism. The overwhelming majority of my interview questions were logical puzzles, generic coding challenges, and algorithm design problems — things that are necessary but nowhere near sufficient.

What Was Missing

I know several people who do a lot of interviewing, and I hear the same line from them over and over: I'd rather hire a smart person and teach them X then hire someone who knows everything about X but lacks creativity, logic, and reasoning.

I get that. The problem is that front-end development is a domain specific skill set. It's not just about mental ability, it's also about knowledge and experience.

Front-end engineers, at their most basic level, are developers who write code that runs on the user's browser. Today that means someone who writes HTML, CSS, and JavaScript and knows the various APIs that browsers expose. The difference between the general term "programmer" and specific term "front-end engineer" is simply the domain where one's knowledge exists. A superstar front-end engineer is probably also a superstar programmer, but the reverse is not necessarily the case (often not).

If you agree with what I've just said, then you can understand my surprise at the absence of some of the following topics from all 23 of my interviews:

• I wasn't asked a single question about new or upcoming HTML APIs.
• I wasn't asked a single question about the differences between various browsers and browser versions or how to target/deal with those differences.
• I wasn't asked a single question about the differences between desktop and mobile browsers or about techniques for building webapps to run on both.
• I was asked just one CSS question (just one!), and it was "tell me the difference between inline and block", a question that even most non-front-end people know.
• I was only asked one question that had anything to do with the DOM, DOM events, or event binding.

What I was asked is a lot of questions like these:

• Write a function that takes two sorted lists of numbers and merges them into a single sorted list.
• Given an array of integers (positive or negative) find the sub-array with the largest sum.
• Determine if a given string is a palindrome.
• Given a large hash table whose keys are movie names and whose values are a list of actors in those movies, write a function to determine the Bacon number of a particular actor.

Again, I don't want to imply that there isn't value in asking these questions. The problem is they have nothing to do with front-end development. As I said before, most smart developers with a strong computer science background could answer all of these, even if they'd never built a website.

So What's Going On?

I'm sure part of the problem is the newness of the need for front-end only positions as well as the term "front-end engineer" itself. It's not a well-defined term and could mean very different things depending on who was using it. I'm willing to admit the possibility that my idea of a front-end role is different from those who were posting the job, but I suspect there's more to it than that.

Another likely causes is that the majority of my interviewers were not themselves front-end engineers. They were senior team members, hiring managers, VPs, founders, etc, but they were usually not front-end engineers. As a result, they stuck to what they knew, and they asked the same questions they always ask.

My Suggestions

Given my recent experience, I want to offer the following advice to anyone reading who might be interviewing a front-end engineer in the near future.

• Front-end candidates should be interviewed by at least one front-end team member (preferably more). If you don't have a front-end team member, find someone you know and trust and ask them to do it.
• Obviously topics like logic and algorithms are important, especially for certain companies, but if you're interviewing for a front-end position, a substantial portion of the questions should focus on the front-end.
• If you really want to ask questions about logic and algorithms, figure out a way to do so that combines your questions with front-end specific knowledge.

To illustrate that last point, instead of asking about the complexity of merge sort, ask about the complexity of this jQuery expression:

$("#nav a")
      .addClass("link")
      .attr("data-initialized", true)
      .on("click", doSomething)

A correct answer to this will demonstrate both an understanding of basic computer science principles as well as a deeper knowledge of what jQuery is doing behind the scenes.

Instead of asking someone to write a function that adds two dates, have them build a simple calendar widget to go along with it.

Instead of quizzing them on CSS trivia, give them two paragraphs of text and see how many ways they can think of to arrange them side-by-side as columns. Then ask them to describe the pros and cons of each method.

Finally, good front-end engineers tend to be very self-motivated. Since browser technologies aren't usually taught in schools, most front-end engineers learned this stuff on their own. So instead of asking them what they know (which is of limited value), ask them how they stay current, and how they keep from falling behind. What are they doing to make sure they'll be better in a year than they are today?

Conclusion

Interviewing is a tricky thing, and even some of the most innovative companies get it wrong sometimes. And interviewing for a front-end position can be even harder because of the ambiguity of the term and the range of expectations that come with it.

The impression I got from many of my interviewers was that most of these companies have only recently begun to realize the importance of dedicated front-end people. Their front-end code bases are starting to get massive and really hard to manage. And part of the problem is the people who manage them aren't well versed in front-end best-practices.

If you're looking to hire a front-end candidate, consider reexamining your interview process. If you're doing some of the things mentioned in this article, you may very well be missing out on some great people.

If you're looking for a job as a front-end engineer, you couldn't be looking at a better time, but if my experience is any indication, I would suggest brushing up on some of your computer science fundamentals. One resource I highly recommend is the MIT Open Courseware lecture series, specifically Introduction to Algorithms.

Lastly, I hope this article isn't just seen as a rant by someone who didn't like his interview questions. That is certainly not my intent. My hope is that I can do my part in raising the bar for front-end work in our industry. And I believe one of the best ways to make that happen is to help companies hire the right people for these jobs.

Interviewing as a Front-End Engineer in San Francisco is a post from CSS-Tricks