Samuel Taggart
Reusing Tests for Built Code
As I have been doing more and more Unit Testing and Continuous Integration, I have often wondered about automating testing of built code. There are promising tools out there for testing built Win32 apps, such as WinAppDriver. There is also Selenium for testing webapps, so if you are into the
Outliers
I’ve had several very interesting conversations lately. I had a great conversation with Allen, Shane, Danielle, and Oli after GDevCon2. I had another fascinating conversation with Fab and few others after the CLA Summit. Most recently I had a conversation after Social Media Day Denver.
All these conversations had
Be The Developer Everyone Wants On Their Team
I’ve been an avid rockclimber and mountaineer for over 15 years. I spend a lot of time helping out with the Colorado Mountain Club teaching classes. I was recently talking to one of the other instructors and he said something that stuck with me. He said there was a
Creating Mocks in LabVIEW
In my last article, I introduced the concept of Mock Objects. The obvious next question is how do you implement them in LabVIEW? Many other languages either have builtin or readily available third party mock objects frameworks. LabVIEW does not. Until Now.
I’ve create some tools for class refactoring
GDevCon2 Initial Thoughts
I finally got home and am starting to recover from GdevCon. Like many of these types of conferences, attending GDevCon is like drinking from a fire hose. Add to that attending the workshop that Steve, Fab, and Joerg put on, lots of late-night discussions at the bar and a little
Continuous Integration and Unit Testing
If you saw my presentation at GDevCon 2, you’ll know that Test Driven Development is about more than just writing unit tests. It’s about the whole development process. However, after each development iteration, you do end up with a bunch of tests. Why not integrate them into your
LightWeight Doubles with SQLite
In a previous article, I mentioned that one reason to use a Test Double was to increase performance. One place where this is evident is in database access. Doubles can be very useful for database operations for the following reasons:
* Isolation from the production database – Isolate any changes you make
Test Doubles In Action
In the last post, I talked about Test Doubles and some various types that we can use and how to implement them. The next obvious question is how do we actually use them in our tests.
Dependency Injection
Understanding Test Doubles first requires understanding the concept of dependency injection. This
Intro to Test Doubles
It’s no secret that many Hollywood actors use stunt doubles. These are specialists that from the outside look and behave like the stars, but have unique talents. The actors do most of the heavy lifting in terms of acting, but for fight scenes, car chases, jumping off buildings, etc.
Unit Testing As An Aid For API Development
If you follow Test Driven Development (TDD) the first step is always to write your unit tests before you write your code. Well in LabVIEW that doesn’t work out quite so well because you need to have a subvi to drop into your test case.
That means that before
Unit Testing as Bug Repellant
Nobody likes bugs, whether they are mosquitoes, black flies, spiders, or software bugs. One mosquito bite is generally mildly annoying but tolerable. Similarly with software, if your customers find a bug, it usually results in mild annoyance. Of course, there are exceptions to both: some mosquito bites can be deadly
Unit Testing as a Delegation Tool
Delegation is hard. There are a variety of reasons, but there are two things I’ve heard quite often from customers, and they are related. They have trouble specifying and clearly communicating the exact requirements to the person they are delegating to. They also have trouble verifying that whatever code
Unit Testing as Documentation
Comments and documentation often lie. The only truth is the code.
Steve Watts commenting on Chris Stryker’s Clean Code presentation at NIWeek 2019
Now I don’t think Steve is accusing the developer who wrote the code or documentation of deliberately lying, but we’ve probably all encountered code