Testing Chrome OS

By Julian Harty

The open-source launch of Chrome OS was announced today, and the source is available to download and build http://www.chromium.org/chromium-os. The entire project, including testing, is being open-sourced and made available for scrutiny and to help others to both contribute and learn from our experiences.

The test engineering team haven't been idle - we're a small, international team and as a result we're having to be innovative in terms of our testing so we maximize our contribution to the project. We had two goals: to take care of short-term release quality and to plan an automation infrastructure that will serve the operating system for many years in the future.

Currently we're combining manual and automated testing to achieve these goals. The manual testing provides fast feedback while we're extending the use of test automation to optimize future testing. In terms of test automation, we're using a collection of open-source tools such as:

• autotest http://autotest.kernel.org/ for complete end-to-end testing of builds
• webdriver and selenium http://code.google.com/p/selenium/ to test through the Chrome web browser

There are some interesting plans and ideas afoot on how to significantly increase the testability and accessibility of Chrome OS - watch for future blog posts on these topics in the coming months!

We have used various approaches to design our tests, including 'tours' (mentioned in various posts on this blog). We are also applying the concept of 'attack surface' used in security testing more generally to determine what to test, from both technical and functional perspectives.

For the launch we devised the 'early-adopters tour'; where we validated the open source build and installation instructions on a collection of netbooks purchased from local stores (we expect many of you will want to build and run Chrome OS on similar machines).

If you're one of the early adopters - have fun building, installing and running Chrome OS and post your comments and ideas here. We hope you enjoy using Chrome OS as much as we're enjoying testing it!

Permalink | Links to this post | 8 comments  

Speaking Tonight at SASQAG

By James A. Whittaker

I am pleased to be speaking tonight at the local (and in my experience one of the finest) QA special interest group, SASQAG. My talk is based on my STAR keynote, but having just released Chrome OS today I am going to be detailing more of our process for making testing more conscious and deliberate.

If you are local and want to attend go to www.sasqag.org for details. I hope to see you there.

Permalink | Links to this post | 5 comments  

How to get Started with TDD

By Miško Hevery

Best way to learn TDD is to have someone show you while pairing with you. Short of that, I have set up an eclipse project for you where you can give it a try:

1. hg clone https://bitbucket.org/misko/misko-hevery-blog/


2. Open project blog/tdd/01_Calculator in Eclipse.


3. It should be set up to run all tests every time you modify a file.
   
   
   
   • You may have to change the path to java if you are not an Mac OS.
   
   
   • Project -> Properties -> Builders -> Test -> Edit
   
   
   • Change location to your java
   
   
   
   


4. Right-click on Calculator.java -> Run As -> Java Application to run the calculator

Your mission is to make the calculator work using TDD. This is the simplest form of TDD where you don't have to mock classes or create complex interactions, so it should be a good start for beginners.

TDD means:

1. write a simple test, and assert something interesting in it


2. implement just enough to make that tests green (nothing more, or you will get ahead of your tests)


3. then write another test, rinse, and repeat.

I have already done all of the work of separating the behavior from the UI, so that the code is testable and properly Dependency Injected, so you don't have to worry about running into testability issues.

• Calculator.java: This is the main method and it is where all of the wiring is happening.


• CalculatorView.java: This is a view and we don't usually bother unit testing it has cyclomatic complexity of one, hence there is no logic. It either works or does not. Views are usually good candidates for end-to-end testing, which is not part of this exercise.


• CalculatorModel.java: is just a PoJo which marshals data from the Controller to the View, not much to test here.


• CalculatorController.java: is where all of your if statements will reside, and we need good tests for it.

I have started you off with first 'testItShouldInitializeToZero' test. Here are some ideas for next tests you may want to write.

• testItShouldConcatinateNumberPresses


• testItShouldSupportDecimalPoint


• testItShouldIgnoreSecondDecimalPoint


• testItShouldAddTwoIntegers

I would love to see what you will come up with and what your thoughts are, after you get the whole calculator working. I would also encourage you to post interesting corner case tests here for others to incorporate. If you want to share your code with others, I would be happy to post your solutions.

Good luck!

PS: I know it is trivial example, but you need to start someplace.

Permalink | Links to this post | 10 comments