This is part three of a
three four nine part blog post where I describe how to use OAuth2 with LabVIEW. See also:
- Part One — Setting up a LabVIEW Web Service Callback Function
- Part Two — The Authentication Process
- Part Three — Improving the Example
- Part Four — Reusability
- OAuth2 and LabVIEW 2020, Using the New SHA256 VI
- OAuth2 and LabVIEW 2020, A Bug in the SHA256 VI
- OAuth2 and LabVIEW — A Bug in LabVIEW’s SSL Certificate Handling
- OAuth2 and LabVIEW 2020, Changes to the LabVIEW Web Servers
- OAuth2 and LabVIEW — Replacing the Web Server
In part one, we created a web service that the authentication process is going to use to call us back with an authentication code. In part two, we wrote code to go through the authentication process and call an example Google web service. Here in part three, we’re going to start writing some tests, replace the JSON parser, and think about what we else we could do to improve the example.
Improvements for Testing
I’m usually not a Test-Driven Development (TDD) kind of guy. That’s where you write unit tests first, show that they fail, and then write the code that passes the tests. I’ll sometimes use TDD when I clearly know what the right answer for a function ought to be. For example, I once used TDD for figuring out a SQL query to a database—I could look at the database and deduce what I wanted the query to return, so I wrote a test for that. Then I iterated until I got a SQL query that returned the right answer, and then iterated until it was efficient.
In our OAuth2 case, I decided from the start not to use TDD. I wasn’t as confident that I knew the “right answer” to each step. But I still kept testability in mind as I went along, and I wasn’t afraid to go back and write tests (and refactor for testability) after the first pass of the app was “done”.
It’s worth talking about the structure of the C# example that I started from. It was badly structured for testability. Here’s a high-level pseudo-code overview of this structure:Read more