Except from some small (personal) projects or tools, is software development a team activity. The bigger the application the more people are involed, and the longer the process is. Starting with a functional analysis all the way to operations, you have many different type of people all with their own function. However, the more the functions are split up, the harder it is to keep ownership and take responsibility and more often the blame game is played. This is simply caused by the fact that it also becomes easier to make mistakes because information is passed on multiple times, and different people will interpret things differently. But even just in development, depending on how you organise the process you can easily cause people to live on their own island.
In the previous post, I have been examining the C++ build tools that are available. As a good Software Engineer, the next step of course is to choose a testing framework. From my experience with Java, I have a couple of requirements on what the testing framework should allow. Most of these requirements come from using jUnit and Mockito, which I think are both outstanding frameworks that allow you to easily test your code.
For my tests I examine the following libraries: gTest, CppUTest, Boost, CxxTest and FakeIt. Some important features I am looking for is easy testing/mocking, readable tests, and the limitations of the framework.
The product we create is a combination of hardware and software, and recently we have introduced the policy of doing a factory acceptance test (FAT) for every vehicle (AGV) that leaves our company. The FAT is meant to make sure that every vehicle that leaves the company works correctly, at least that is the theory because in practice we still have a lot of problems with getting everything working on the customer’s site. The goal of this blog post is to go into depth about the reasons for doing a FAT, the pros and cons and why it is failing for us.
Crucial to good Object Orientation, is the separation of concerns and capsulation. This means your objects need a clear API that limits the way the internal state can be changed. The object itself must be responsible for the state and must guard its integrity. While the API defines what operations are allowed, these methods have restrictions of their own. It is essential that the parameters provided to these methods are within the limitations. The only solid way of checking these values is by using preconditions.
When writing software we often are only focused on just that: getting the feature done. With the rise of Test Driven Development (TDD) some of us will first write tests before the actual code and this is great. Personally I like the concept of TDD, but I can’t seem to make myself adhere to it as I am always to eager to write the code instead of first write the test.
Another reason I don’t do TDD is that I find it hard to write a test for something that doesn’t even exist yet. At least the public interface should exist, but this interface can change often during my implementation because I don’t come up with a full design in the beginning.
But even though I don’t do TDD, I spend a lot of time writing unit tests, making sure all of my code is being covered and that I didn’t forget anything. I do this because this is the only way to avoid bugs in the future. Others however will spend either much less time on writing tests or none at all but will write a lot more code. To an outsider it may seem like these developers are more productive as they output more code. There are however a couple of problems with this idea.
For those who are confused about the title, I am not going to talk about our planet (although it is essential we take care of it). The environment I am referring to is of course the development, testing, build and production environment. All these environments can be different and in most cases they are. There are a couple of reasons for this:
- You have different customers all having different hardware and software in production you have to integrate with.
- There is a difference between your company and the customer in setup, which would be very expensive to change.
- Having a full production environment for development is almost always too expensive.
So unless you are willing to change all of your environments and pay a serious price for it, your environments will differ. And while these differences can be cumbersome and make software development harder, a lot can be done to overcome most of these problems.
Windows 10 is gaining popularity and so does Edge, the new browser that comes with it. With this increasing popularity it becomes important to verify the compatibility of your software with the new platform. Recently I was asked to verify that our Software behaved correctly when using it with Microsoft Edge. While it would have been possible and easy to just do some manual checks, this would not suffice and will not guarantee future changes to be compatible with Edge.
But since we already have automated tests for other browsers, it makes sense to just add Edge as a browser on which these tests have to run. Trying some new technology can be challenging, and often problems arise. Trying to get our Selenium tests running with Edge was no exception.