Runtah

Thursday, March 12, 2015

FitNesse and todays date with net

I have an acceptance test that says I need to validate the age of majority in each of the different states and provinces. Here is a simple example:

Given Mary who is born January 5, 1995 and lives in Manitoba

When she asks if she is the age of majority

Then return no

The test above is faily simple and I could write it like this in the wiki as a Column Fixture (using the fitSharp.dll to test C# code)

!|Check Age of Majority|

|Province State|Birth Date|Am I Underage?|

|MB |5-Jan-1995|Yes |

The problem of course is that this test will start failing on January 5, 2013 when Mary turns 18. Also, it does not perform the boundary testing that I would like it to do in order to test someone who is 18 today vs. someone who will turn 18 tomorrow. In order to improve this test, I investigated some other date functions in FitNesse and a plugin by James Carr that allowed you to add days to the current date. These work ok for smaller calculations like "Given document ABC, When it is 30 days old, Then archive it". However, this would be a little more cumbersome for birth dates when adding 18 years (esp. with leap year calculations) and the !today function in FitNesse does not work in ColumnFixture wiki tables. So, I found a simple way to meet my requirement.

First, I wrote a class in C# that accepts two parameters to Add or Subtract Years and Days to the current date. The class uses C#s simple DateTime addition to add or subtract the years/days from today and returns the result. You could easily extend this to add months or add other functionality required in your tests:

namespace FitNesseTutorial.Tests

{

public class GetDateBasedOnToday : ColumnFixture

{

public int AddYears;

public int AddDays;

public DateTime ResultingDate()

{

return DateTime.Today.AddYears(AddYears).AddDays(AddDays);

}

Then in FitNesse at the top of my script for this story I call GetDateBasedOnToday and store the resulting values in FitNesse variables. Finally, I use the variable names through my script to reference the underage and of age birth dates. Here is an example:

The FitNesse script:

Get underage and of age dates for 18 and 19 year olds

!|Get Date Based On Today |

|Add Years|Add Days|Resulting Date?|

|-18 |1 |>>UNDERAGE_18 |

|-19 |1 |>>UNDERAGE_19 |

|-18 |0 |>>OFAGE_18 |

|-19 |0 |>>OFAGE_19 |

!|Check Age of Majority|

|Province State|Birth Date |Am I Underage?|

|MB |<<OFAGE_18 |Yes |

|MB |<<UNDERAGE_18|No |

|BC |<<OFAGE_19 |Yes |

|BC |<<UNDERAGE_19|No |

In FitNesse, the final result including the acceptance criteria above looks like this:

(Note: The example above should probably be written as a unit test because it is fairly straightforward, but it simply illustrates how to use the date logic that Im using as part of larger acceptance tests.)

Code updates required for Apps Script advanced services

The APIs for three of Apps Scripts advanced services — Analytics, BigQuery, and Prediction — will undergo breaking changes on Monday, November 18. If you dont update your code to the new syntax before then, youll receive error messages such as Required parameter is missing.

Advanced services allow you to easily connect to certain public Google APIs from Apps Script. Were working to expand and improve our advanced services, and as a side effect some methods and parameters that were incorrectly listed as optional are now required.

On November 18, these services will switch to use the new method signatures shown in the tables below. To learn how new arguments should be structured, refer to the documentation for the underlying API. For example, the documentation for the BigQuery services Jobs.query()method shows the valid properties for the resource object in the "Request body" section of the page.

Old	New
`Analytics.Management.Uploads`
.deleteUploadData( accountId, webPropertyId, customDataSourceId, optionalArgs)	.deleteUploadData( resource, accountId, webPropertyId, customDataSourceId)
`BigQuery.Datasets`
.insert( resource, optionalArgs)	.insert( resource, projectId)
.update( resource, optionalArgs)	.update( resource, projectId, datasetId)
`BigQuery.Jobs`
.insert( resource, mediaData, optionalArgs)	.insert( resource, projectId, mediaData)
.query( projectId, query)	.query( resource, projectId)
`BigQuery.Tabledata`
.insertAll( projectId, datasetId, tableId, optionalArgs)	.insertAll( resource, projectId, datasetId, tableId)
`BigQuery.Tables`
.insert( resource, optionalArgs)	.insert( resource, projectId, datasetId)
.update( resource, optionalArgs)	.update( resource, projectId, datasetId, tableId)
`Prediction.Hostedmodels`
.predict( project, hostedModelName, optionalArgs)	.predict( resource, project, hostedModelName)
`Prediction.Trainedmodels`
.insert( project, optionalArgs)	.insert( resource, project)
.predict( project, id, optionalArgs)	.predict( resource, project, id)
.update( project, id, optionalArgs)	.update( resource, project, id)

If you want to prepare your code ahead of time, you can add a try/catch around your existing code that retries with the new method signature if the old one fails. For example, the following sample applies this approach to the BigQuery services Jobs.query() method:


  var result;
  try {
    result = BigQuery.Jobs.query(projectId, query, {
      timeoutMs: 10000
    });
  } catch (e) {
    // Refer to the BigQuery documentation for the structure of the 
    // resource object.
    var resource = {
      query: query,
      timeoutMs: 1000
    };
    result = BigQuery.Jobs.query(resource, projectId);
  }

We apologize for inconvenience and look forward to sharing exciting news about advanced services in the coming weeks.

Eric Koleda profile

Eric is a Developer Programs Engineer based in NYC on the Google Apps Script team. Hes previously worked with the AdWords API and enterprise content management software.

Google Apps Script with UI Properties and New Sites

Weve just finished pushing one of our most feature-rich Google Apps Script releases ever! So much has been added and improved in this release that its hard to fit it all in one blog post. Ill run through the highlights, but please make sure to check out the Release Notes for a complete list of changes in this release.

The biggest news is that UiApp is now available to all users! UiApp allows you to build user interfaces, giving scripts the ability to show a friendly interface, which is a necessity for less technical users. We’re very happy to make this formerly Premier feature available to everyone. For more information, see the UiApp code samples and reference documentation.

Next, weve added ScriptProperties and UserProperties. These features allow scripts to store key:value data per user, or per script. ScriptProperties are a great place to store passwords and other script-specific information. UserProperties are useful for storing things like user preferences. For details on using these properties, check out the documentation.

Weve added some new functionality to Sites and cleaned up some inconsistencies and bugs. This has greatly simplified the API, while at the same time making it more powerful and flexible. Some of these improvements have required changes to the API, which is documented in the SitesApp reference guide.

Finally, weve updated the Apps Script editor with a bunch of convenient features. You can perform Find & Replace in the editor. Script revisions are now available, so that you can see a history of changes to your scripts. Lastly, we’ve added the ability to change the timezone of a script, something that we hope will make developers’ lives easier.

The remaining items in this release are listed in the Release Notes. Were look forward to hearing your feedback about all the new changes, and would love to see what you do with the new features. Some large improvements and features are in our pipeline, so stay tuned!

Posted by Don Dodge, Google Apps Team

Want to weigh in on this topic? Discuss on Buzz

But does it work an agile metric

Ive said publicly at conferences and other gatherings that my passion for agile and lean began years ago after a particularly troubling project that tried to be agile. While that project had a strong team and eventually delivered a product, it had trouble with quality, scope and budget. In retrospect the biggest problem was that we had little knowledge of what it meant to be agile - our process was flawed. As a leader of that team, I took responsibility for the result and began a search to understand agile. Borrowing a phrase from the agile manifesto, I wanted to uncover better ways.

After implementing several changes to our process, my projects over the years seem to have improved significantly. But how do you measure this? While no metric should stand alone, here is one quality metric that Im experimenting with:

((# of high defects * 5) + (# of medium defects * 3) + (# of low defects * 1) / Total project hours * 100.

The troubled project had a score of 18.7. My most recent project score was 1.2 which is almost a 1600% improvement on quality. I think Ill keep doing this agile thing.

P.S. Im heading to Agile2010 this summer. Give me a shout if you are going and we can find ways to de-brief together over lunch or dinner in Orlando.

Announcing the Google Drive Installation Scope

Not long after the Drive SDK was first released, we started receiving requests for a simpler developer and user experience. It took too long for developers to get started, and users were sometimes confused by the ways apps were installed. We’re now announcing a new feature that helps address these concerns: the Drive installation scope.

As the name suggests, this new OAuth 2.0 scope lets users install an app by approving an access request. Along with all the other levels of access you can request from users, it’s now possible to ask users for permission to install your app in their Drive.

This means that an app, or an app’s promotion page, could present an option to “Install this app in Google Drive,” and then users who select this option would interact with an OAuth 2.0 dialog that requests the installation scope. For example, the following script creates an “Add to Google Drive” button that could be embedded in a web page:


<script src="https://apis.google.com/js/client.js"></script>
<script>
var CLIENT_ID = 123456789.apps.googleusercontent.com
function installDriveApp() {
  gapi.auth.authorize({
    client_id: CLIENT_ID,
    scope: https://www.googleapis.com/auth/drive.install,
    immediate: false
  }, function(authResult) { // Callback when installation complete });
}
</script>
<button onclick="installDriveApp();">Add to Google Drive</button>

On clicking this button, the user sees a standard OAuth 2.0 dialog box like the following (text for the installation scope is expanded in this example):

When the user approves these scopes, the app is installed for the user. Then, once it is installed this way, the app appears in the user’s Open with options as well as the Create > more contextual menu for files of registered MIME types.

Apps still need to specify primary and secondary MIME types when they enable the Drive SDK in the APIs console. But, unlike before, there is no need to install via the Chrome Web Store in order to get UI integration -- web store integration is entirely optional (though recommended).

Essentially, Drive now offers three levels of integration, which apps can combine according to their needs:

Simple API access with the Drive API enabled.
UI integration, with API access, the Drive SDK enabled, and OAuth-based installation.
CWS-based integration, with all of the above plus web store installation and marketing/upsell features.

For guidance in getting started integrating your app in any of these ways, see “Build a Drive Web App” or "Integrate with the Drive UI" in the SDK documentation.

We still recommend that developers consider the many benefits of creating a Chrome Web Store listing for their application. In addition to providing ease of installation for users “shopping” in the Drive app collection, a web store listing provides helpful features to market and promote an app. Our usage analysis shows that apps in the Chrome Web Store receive more usage than apps that aren’t listed. But now, with the installation scope, you can get started developing and testing your app more quickly and then list it in the Chrome Web Store when you’re ready.

If you have any questions about the installation scope, don’t hesitate to let us know on our Stack Overflow tag, google-drive-sdk.

Eric Gilmore

Eric is a technical writer working with the Developer Relations group. Previously dedicated to Google Apps APIs, he is now busy writing about all aspects of the Google Drive SDK.