Uri is a Firebase Expert based in Tel Aviv, Israel. He works at WatchDox, organizes the Tel Aviv Google Developers Group, and is an avid Angular fan.
I built an open-source project called firebase-server to implement end-to-end tests in my own application. With firebase-server, my end-to-end tests are now running 40% faster and I no longer depend on an Internet connection for running the tests in development.
Because Firebase is a cloud service, it poses some challenges for performing automated tests. For unit tests, using a mock for the Firebase client library will work well. If you are writing a web application, you can quickly mock just the methods you use with either Sinon or Jasmine, or use MockFirebase, an open-source Firebase mock.
When it comes to writing end-to-end tests, however, you usually want to test the system as a whole, including the integration with the real Firebase client library to verify that the realtime synchronization between clients is functioning correctly. In addition, the end-to-end testing code runs outside the context of your application and you should make some assertions about the data it saves to Firebase.
Before building firebase-server, I used the Firebase client library in my end-to-end tests to talk directly to the Firebase cloud service. The issues with this method were that I needed an internet connection to run the tests and my tests ran slowly if my internet connection was lagging.
Frustrated with my end-to-end tests occasionally timing out, I started looking for a solution. MockFirebase would solve the problem only if my testing and app code lived within the same process, and even then, I would not be testing the real Firebase client library.
I decided that the best solution would be to put MockFirebase into a separate process, and make the Firebase client library connect to that process. This is when firebase-server was born!
firebase-server is a simple Node module which speaks the Firebase Wire Protocol, and can be used as a proper substitute for the real Firebase server in your e2e testing scenarios. You can also use it to develop code against Firebase in times when you don't have an internet connection.
First, install the package from npm:
npm install --save-dev firebase-server
Next, you can launch the firebase server by doing the following:
var FirebaseServer = require('firebase-server'); new FirebaseServer(5000, 'test.firebase.localhost', { /* You can put your initial data model here, or just leave it empty */ });
Before you can connect to your Firebase, there is one limitation of the client library we need to work around: it requires the hostname of your firebase to include exactly two dots. You can work around this by adding a hosts file entry pointing 'test.firebase.localhost' to the local IP 127.0.0.1.
'test.firebase.localhost'
127.0.0.1
Add the following line to your hosts file:
# Your hosts file can be found in: # Linux: /etc/hosts # Mac: /private/etc/hosts # Windows: c:\Windows\System32\Drivers\etc\hosts 127.0.0.1 test.firebase.localhost
For more information about editing your hosts file, see this page.
Now, everything is ready and you can switch to your local Firebase server. Simply change the connection string from https://myFirebase.firebaseio.com to ws://test.firebase.localhost:5000. For instance:
https://myFirebase.firebaseio.com
ws://test.firebase.localhost:5000
var client = new Firebase('ws://test.firebase.localhost:5000'); client.on('value', function(snap) { console.log('Got value:', snap.val()); });
If you do not wish to edit your hosts file, you can also use ws://127.0.1:5000. This trick seems to work inside Chrome and Firefox. With Node.JS, you can use another trick: overriding the constructor of the faye-websocket Client. Check out the firebase-server unit testing code for an example.
ws://127.0.1:5000
I'd love to hear any suggestions you have on firebase-server. You can file an issue or submit a pull request on GitHub, or send me your feedback on Twitter, I'm @UriShaked.
Kristel Viidik is the co-founder and CEO of Testlio where she handles everything from answering every support e-mail to acquiring new customers and making them fall in love with Testlio.
Testlio is a full-service software testing solution. We remove the need to build an entire QA department in-house by partnering with our customers and assisting in managing their testing process using our community of top testers. ... Our vision is to completely change how QA is done.
Many companies are afraid of outsourcing because the quality tends to suffer. However, compared to hiring your own testers in-house, outsourcing is much more affordable. At the affordable cost of outsourced prices, Testlio gives companies a dedicated team of software testers with years of experience collectively.
I'm a professional tester. I was looking to do some testing on the side because it's something I genuinely enjoy. I joined several of our competitors as a tester and found that their model rewarded the quantity of bugs caught rather than the quality of the findings.
Serious flaws quickly stood out. I didn’t feel like I was a part of the testing team for each app I worked on. Testers weren’t communicating or collaborating with one another. It was like we were testing in a vacuum.
This is important because creating a high-quality app is a team effort. Testers, developers, designers, and product all need to work together. Quality is everyone’s responsibility. Anyone can find the low hanging fruit, but if you really want to make an excellent app, everyone involved in the product has to work together.
To date, we are rapidly expanding our customer base and we pride ourselves on having a community of the top testers in the world.
Firebase has been a significant part of our success in bringing together our awesome community of testers.
Communication between testers and customers is incredibly important on our platform. To facilitate this, we’ve created a real-time chat system using Firebase. If it weren’t for Firebase, creating this chat system would have been prohibitively difficult.
Testers and customers communicate on projects. It’s important that there aren’t any bug report redundancies on these project reports. We use Firebase to do real-time checks while testers are submitting a bug to prevent these redundancies from being submitted. This way, no one’s reports will be overwritten or duplicated.
Testers applying to Testlio have to go through a rigorous verification process. A part of this process is a mobile testing game we’ve created. This game serves as a quiz to assess the applicant’s testing skill. We use Firebase to keep track of each applicant’s progress in the game and entire application process.
Testlio is currently built with php, HTML5, node.js, socket.io and redis with AWS for hosting. However we are in the process of completely revamping our stack. In the very near future we will be using Koa, io.js, and React.
One of the features our customers love is App Store Reports. A lot of companies are interested in what their end users are telling them. App Store Reports aggregates the data from the app store and sorts them by feature and/or product areas so customers can see exactly what’s doing well and what needs improvement.
Testlio is also very popular for beta testing. Our platform makes it easy to add beta testers and customers receive all their reports in one place. Testlio has made this entire process super simple.
An exciting new feature is automation support: you write your test scripts on our platform and we take care of execution. All the results are available in Testlio and you’re immediately notified of any failures. We’re currently testing this feature with a few of our early customers and it will be available to everyone very soon.
We're constantly improving our product. Not only are we completely changing our technology stack, but we're also revamping our design, onboarding, and general UX of the product. We value user feedback more than anything, so if you have any suggestions please tweet them to us @testlio or e-mail us at hi@testlio.com
The Ember CLI is a command line interface that provides a default project structure for your EmberJS application and makes it easy to develop according to Ember's conventions. It is quickly becoming the default way to build Ember apps. After hearing about all of the new features for Ember CLI at EmberConf earlier this month, I was excited to try it out with the latest version of EmberFire, Firebase's adapter for Ember Data.
If you're new to Ember or the Ember CLI, this video will walk you through Ember's core concepts and the basics of developing with the CLI. In 9 minutes you'll learn how to build a chat application that uses EmberFire to persist data:
To learn more about using Firebase with Ember you can check out our EmberFire quickstart or step by step guide. I'd love to hear what you think of the screencast. Leave your feedback in the comments or find me on Twitter @SRobTweets.
Hi, I'm Tim! I’m the newest member of the Firebase UX Team. I've been an avid Ember user for two years, and I've spent my first few weeks at Firebase adding new features to EmberFire. On the UX team, I’ll be working on building out features in the App Dashboard.
Last week Sara and I attended EmberConf 2015 in Portland, Oregon. We had a great time meeting a ton of awesome people in the Ember community and hearing about what's coming up for Ember in 2015. After getting feedback from many of you, today we're releasing some new features in EmberFire, our official bindings for EmberJS.
As Ember development moves towards Ember CLI, the latest release includes much better CLI support - you can easily install EmberFire as a CLI addon and the FirebaseAdapter will automatically be initialized in your application adapter. This release also adds support for querying your Firebase data. Details on both new features are below. Also, a special thanks to Matt Sumner for his contributions to this release on GitHub.
FirebaseAdapter
EmberFire now supports ES6 modules and is packaged as an Ember CLI addon by default. You can get started with EmberFire in your CLI app in two steps:
From your CLI app’s directory, run the command:
$ ember install emberfire
This will add Firebase as a dependency in your bower.json file and generate app/adapters/application.js for you.
bower.json
app/adapters/application.js
The ApplicationAdapter generated by running the install command references the config.firebase variable in your config/environment.js file. Next, update your Firebase URL to that file:
ApplicationAdapter
config.firebase
config/environment.js
$ firebase: 'https://YOUR-FIREBASE-NAME.firebaseio.com/'
Now your Firebase data will automatically be synced with the Ember Data store.
The latest release also loosens our Ember Data requirement. You can use EmberFire with Ember Data beta-11 through beta-14.x.
beta-11
beta-14.x
You can run our example blog app by running ember serve from the root of the emberfire/ directory.
ember serve
emberfire/
For those of you who aren’t using Ember CLI yet, don't worry - you can still use EmberFire! Just include EmberFire and it’s dependencies in your HTML from our CDN. Check out the instructions in our guide for details.
When we released additional querying methods, many of you asked for direct support for this in EmberFire. This 1.4.1 release includes findQuery support! You can now use Ember’s findQuery method to order your Firebase data by a specified child or by key. Using this sample Firebase of dinosaur facts as an example, the following query will return the two tallest dinosaurs:
findQuery
//app/routes/dinosaurs.js export default Ember.Route.extend({ model: function() { return this.store.find('dinosaur', { orderBy: 'height', limitToLast: 2 }); } });
Check out the EmberFire documentation on findQuery for more details.
Finally, we’d like to hear what you think as we continue to improve EmberFire. We encourage you to submit a PR on GitHub, and share your feature requests with us @Firebase on Twitter or in the comments below. We’re excited to see what you build with Firebase and Ember!
Important note: Firebase private backups have changed since this blog post. Please see the updated details here.
.json
security_rules.txt
