2018 – Stephen Adams

What companies want from an Ionic developer

I’ve recently started a new Ionic project, where we are already using Ionic v4. Through chatting with the team, I’ve realised that being an Ionic developer is a specialist role and by working as a developer in such a specialist role there is more to it than being able to code.

When a company decides that they are going to be developing their new mobile project in Ionic, they are making an investment in a technology that is not yet the norm for building mobile apps. They have spent the time to look into alternative ways for creating their app, they need to be sure that the road they are going down will mean that the app being built can fulfil all the business needs that they have for the app.

With native app development, the path has been proven. There are tons of examples of business apps developed in Swift or Java that show whatever the company’s needs are a native app can be built to meet those needs. But as we know as a hybrid developer, there are a few drawbacks from building native apps. There is cost, there is timescales and availability of development skills. All things to think about when deciding what to use to get their app built.

So when a business has decided that they want their app built using Ionic as the ‘Ionic developer’ who is working on the project you are seen as the expert. Not only should you be able to develop an app with Ionic, but you need to be able to guide the business through the process of having building a hybrid app.

The sort of advice you will need to help the business with could include, how will the app perform in relation to other apps they may have seen? You may have to convince the business that the app is fast, or appears fast to the user. How will you add features that show the app is fast? You’ll have to suggest ways like having loaders when data is being retrieved, showing update messages when a form is being submitted. Do you know how to partially load data into the view, so the user sees something as soon as data has been received.
You have to also show them how an Ionic app will be deployed. What are the various options? Are they going through the App Store or are they looking to use the Ionic Pro tools, do you know what the Pro Tools do? If they are using them you’ll have to help with the deployment stage.

Security is an important part of any business app, so you’ll have to know about the different approaches there are to securing an Ionic app. You’ll have to be able to advise on what Cordova plugins could be used to store data securely. You may also need to what other options they could use to secure an app. Is biometrics an option, could they use the native finger print reader within the app? How would you suggest API tokens are stored and passed with every API call?

If the business has an existing design style, how will that work within a mobile app? Does it work across all platforms and still look and feel as a native app should for the user? You will have to give the business advice on how the app will look in order to work for the user, without trying to tell a professional designer, who knows more than you do, how to design.

There are a lot of questions that a business will have when going through the process of having an Ionic app developed. As the Ionic developer you need to be able to guide the business through this process. It’s not just a case of just sitting behind a monitor with you headphones on writing Ionic code, you need to actively work with the business in all aspects of building the app.

But there is more we can do as Ionic developers. We can write blog posts on how we solved these types of questions. There are many brilliant blog posts on how to create an app with Ionic, but there aren’t many about how an Ionic developer has used the framework and the tools Ionic provides to solve a business need.

I’d like to see more blog posts on how security was built into an app, how data is stored securely in the app. What methods someone used to shows that the app is performing really fast, how was this monitored? What ways was the UI setup to show to the user the app was performing well for them?

There are many examples of posts about the setting up and building of an app and this will continue now we have Ionic 4 coming out with its support for multiple frameworks. I’m in the process of writing a book about Angular and Ionic, where I go through the basics of creating an Ionic app. This is all great for new developers coming to Ionic, the more we have the better.
But I think we also now need to show how we as Ionic developers are using what the framework provides to show businesses and enterprise level companies how Ionic can be a viable option for their next business application.

As Ionic developers we need to be this guide for businesses as well as developers. With Ionic 4 coming soon its time we stop telling each other how great Ionic is and now start telling businesses how great an option Ionic is for their next app.

Upgrading Your Approach to Angular from AngularJS

When upgrading an AngularJS app to Angular, there are a couple of routes you can take. There’s ngUpgrade, which is the official migration path set out in the Angular docs. There is also ngMigration, a fantastic tool that reviews your existing AngularJS codebase and lists the actions you need to take in order to migrate to Angular. Both ways show you what to do with your codebase in order to get from AngularJS to Angular, but the trickiest part is for developers new to Angular, who may have been working on one large AngularJS application for the last few years and have had no exposure to Angular. Is for them to understand the new approach Angular is taking.

In AngularJS you had scope, controllers, directives and services/factories. In v1.6 components were brought in (though they are really just directives with controllers built on). Now in Angular, you have components, modules, providers, pipes, classes, interfaces (though both features of TypeScript). You have type safety on top of all this.

So for the legacy AngularJS developer, there is a whole mindset shift that needs to happen besides just upgrading the codebase.

They need to know what effect having everything as a component has on the structure of an application. What is the relationship between parent/child components, how is data transferred between parent/child components? How does the module system need to be used? A legacy developer may just add all their components to the single module, creating one large monolithic module. Instead of taking advantage of the module system to break down the application by having feature modules. They need to know about the by feature approach to the folder structure of an application. They need to know about where the common features will go, is there a core folder that contains all the components/providers that aren’t part of a feature?

Another area that legacy AngularJS developers can slip up on is using TypeScript and embracing the type system. It could be far to easy to just set everything with a type of any and not using the benefits that the type system gives you. Like better tooling, picking up spelling errors before running the app, more efficient code that the TypeScript compiler can optimise to make the application run faster.

The advice I’d give if upgrading to Angular

Read the ngUpgrade guide
Read the Angular style guide in order to understand the approach to writing an Angular app
Understand the module system, how to use it to divide up your app
Understand the relationship between parent/child components
Learn at least the basics of TypeScript and creating Types

You can’t go from AngularJS to Angular and expect to use the same approach you had. Angular is so different from AngularJS, that it is not just a case of changing a few JavaScript files to TypeScript. It’s a complete shift in approach to not only writing Angular but developing front-end applications altogether.

This week in Angular

Photo by Mr Cup / Fabien Barral on Unsplash

Here is a list of news stories I’ve found interesting from around the world for the Angular platform.

Apps That Work Natively on the Web and Mobile

From the Angular official blog, we have a post about NativeScript and how you can now, thanks to Schematics in the Angular Cli, share code between desktop and mobile apps.

One codebase for both desktop and mobile, something that is very powerful. Max Lynch from the Ionic team did Tweet at the time that Ionic has been allowing developers to share code between desktop and mobile for a long time.

2 New Tools to help with AngularJS to Angular Migrations

Another story from the official Angular Blog, on two tools that will help to make upgrading from AngularJS to Angular. One tool is a CLI tool called ngMigration. This tool will analyse your application and gives a list of recommended changes you need to make in order to prepare for migration to Angular. This is extremely clever and gives anyone a great starting point when you want to migrate to Angular.

The second tool, is a forum where tips and tricks can be shared on how to migrate to Angular, and a place to ask for help during a migration.

Nrwl Nx 6.3: Faster Testing with Jest

The Nrwl team has just released a new update to NX, now at version 6.3. This release now has support for Jest, the test runner from Facebook. Now with this latest release Jest can be used as the test runner instead of Karma. According to their blog post, the main reason for using Jest over Karma is performance. Jest is fast, but not only that Jest has better reporting, uses Node so no need to link to the browser and Jest has excellent Mocking.

I’ve not used NX as yet, but I can see there is a really need for large scale Angular applications to have fast running tests. With this new release of NX, Nrwl are building an excellent tool for enterprise Angular teams.

RxJs Observables versus Subject

Continuing his brilliant articles on RxJs, Cory Ryan compares the different types of Observables that RxJs provides. Cory has written a number of great articles on RxJs, as well as articles on Tree Shaking in Angular, classes in TypeScript. His blog is a great resource for any Angular developer.

Angular Patterns 3: flexible and scaleable design of complex page

In this article, Adriano di Lauro goes through a set of patterns he has developed over his time developing Angular applications. There are many articles about how to use the latest features of a framework, or how to use a certain library. So it’s good to read, for a change, an article about how someone approaches a problem within Angular. Adriano also has articles on how he organises modules and what considerations to have when writing reusable components.

There is a lot happening within the Angular eco-system, but these posts I found really interesting.

The Business Case for Unit Tests

Recently I read this great article on the DZone website called The Business Case for Unit Testing by Erik Dietrich In this article, he sets out six reasons why Unit Tests should be considered as a serious business need and what benefits they bring to a business.

Two of the points Erik makes I feel are extremely important as to why Unit Tests are so a crucial part of an application. One, The Test Suite Reduces Deployment Risks, by having a good set of tests that can be run when the application is about to be deployed. There is less risk that issues will occur during this deployment phase, making the application deployment smoother and getting the application to your users quicker.

How do Unit Tests Reduce Deployment Risks?

As an application is being developed, your development team will continue to write test, this leads to greater test coverage of the application.
When it comes to making a deployment to your users, having this large set of tests, which can be run before each deployment, there is more chance that any bugs that have crept into the application will be found before the application is deployed to the end-user.
Within your release process, you can have all the unit tests be run automatically. If any tests fail, the deployment of the application will be stopped. Then the team can look at what caused the test to fail, and fix this issue.
Having these issues caught before the application is deployed to the end-user, means that they will have confidence in using the application. You also as a business owner can have confidence that your application is being released to your paying customers, with the application being thoroughly tested.

The second great point that Erik made was Tighter Feedback Loop for Time Savings. In this section, Erik makes the point that having Unit Tests improves the feedback loop that developers use to see if errors are appearing in their code.

What is this Feedback Loop?

This feedback loop that Erik mentions is where the developer is given feedback straight away if there is a problem in their code, it’s not doing what it should be doing, the code is not fulfilling the requirements that have been set out in the user story.
For example, if you have an Angular based business application, that has the requirement that when the user clicks on the Login button, the application should open a login panel.
So the developer builds the Login section and adds a Login button that loads the Login section. As part of this, they need to check that the user is not already logged in. Now in their code, they could have a function which clears any current login sessions. This code could have a bug in it where it fails to clear all the logged in sessions. So being a good Angular developer, they write a Unit Test that checks for the list of login sessions, and confirms that this list is 0 when the Login button has been clicked (this confirms that when the user clicks Login, any previous logins have been cleared so they never see someone else account details).
Now 6 months later a new requirement has come in that the Login process needs to write to a database when the login was made so a report can be produced to show user logins. As part of adding this new functionality the clear logins code gets amended and a bug is introduced. It looks like its still working, but the login sessions aren’t being cleared.
Without a Unit Test to check that the functionality of the code still works as expected, this bug could get through to the paying customer, causing major problems.
With the developer using Unit Tests, they would get feedback straight away that the changes they are making to this Login process have caused this new bug. They will fix the issue even before it goes any further.
As Erik says, A unit test suite makes you much more likely to catch errors sooner than later. It does this by tightening the feedback loop. so with a good test suite in place, you’re far less likely to spend disproportionate amounts of time tracking down, reproducing, and fixing issues and the code you’ve built on top of them.
Reducing this time tracking, reproducing and fixing issues, saves money and gets the application out to the customer sooner than later.

Unit Tests are important to a project, especially a long-term business critical application. They have a real benefit to the business and are not something a developer is just ‘wasting’ time with.

The full article by Erik has some really good points and is well worth reading, whether you are a developer or a project manager of a business owner.

Why you should allow developers to write tests for existing code

Is it possible to add Unit Tests to an existing application and if you do decide to add tests to a project, what benefit will this have to an existing application?

I’ve worked on a few projects where the application has been started, the first few features of the app come to life and before the developers realise the application is nearly delivered to the end user, without any Unit Test coverage.
One of the main reasons for this is when an application is started there is usually a tight deadline, or a push to get something out to the end user within the first sprint and there isn’t time considered for the writing of tests. The unit test theory is that a test should be written before any code is written, but with time pressures writing tests is always something ‘we can do later’.

But can unit tests be added to existing code? And what benefit will this bring?

It is possible to write tests for existing code, it is, in fact, a good practice to go through this process for a number of reasons.

It provides confidence that new changes do not break what is already there

First, it stabilises the codebase of the application, providing confidence that any further changes are not going to break the existing code. Once tests have been written for the existing code, developers know that there is a quick way to check if the new feature they are adding is not breaking what is there already. As they go through developing this new feature having the test runner going in the background running all the tests the developer will see straight away if the change they are making is stopping existing code from working as it did before. They will get a red warning, telling them exactly what is no longer work and why.

It highlights areas to developers where code can be improved

The second reason is when writing tests for existing code developers will notice areas where the code can be improved, optimised. When writing a test you need to know exactly what the code you are testing is doing and how it works. Through this investigation, developers will see ways it can be refactored to make improvements. Once this code has been refactored and improved the test will ensure that any further changes don’t break this improved codebase.

Its a great way to onboard new developers to a team

Another reason that allowing your developers to write tests on existing code is it is an excellent way for new developers to a project really understand how an application works. If for example, you have a large enterprise business application, that has many business rules. It can take a new developer to the team to both understand the business rules, but also understand how the application currently supports these rules. If for their first few weeks on a project they are given the task to write the tests for a certain section of the application, maybe an API the application provides or a set of services that the application uses to process user orders. Through writing tests, the new team member will learn, in depth, how the current application works. They will also be involved in how the application is built, deployed, how the processes the team has for committing code, what rules there are in place for writing code. All this they can do through writing tests without affecting the code of the application.

How can tests be added to your existing project?

If you are a project manager or the business owner of an application and your team have said that the Unit Test coverage for the application needs to be improved. There are some things you can do to help this.

Writing tests should be defined as Sprint stories

You don’t need to stop development on new features just to have your team write all the unit tests for the application. This can still continue, but you need to add time to each sprint (if that’s the method you use) to allow the developers time to write tests for part of the application. When it comes to sprint planning have a few stories for writing tests. Prioritise areas of the application where test coverage is low, maybe focus on areas that are more stable, an existing API for example or the data model which isn’t going to change for a while. Assign these write tests user stories to the newer members of the team, so all they can go through all the development processes the team uses.

Improving test coverage can be a gradual process

The existing application doesn’t need to have 100% code coverage straight away. It’s better to add tests gradually as the project progresses, tests can be bought in for existing code. This does mean there is a risk that changes could break another piece of existing code, but if the tests are being written this risk will get less and less the more coverage your application has.

Allow your developers to write tests

When you are planning some work with the team, a new feature to be added. Allow time in estimates for the developers to write tests. If this time is not in the estimates developers will find that they don’t have enough time to not only write the new feature and write the tests. So the tests will start to be left, this will cause the test coverage to reduce over time and you’ll be back to where you were before, with an application that has a lot of functionality and existing code, that isn’t covered by tests.

Your QA team and clients will thank you

Finally, an application that has a higher test coverage, will have fewer bugs. New features won’t cause new bugs to appear in the existing application.
This makes the QA team happy, for them it means that they can be confident that what is already in the application still works as before. They don’t need to thoroughly test the entire application every time there is a release. They can quickly test the existing application and then focus on testing the new features. Any bugs that crop up should be caught by the developers during the development phase when they have their test runner quietly running along as they write code and then warning them as soon as any issues come up. Instead of the QA team raising a new bug.
Having the QA team raise these minor bugs which could have been caught by unit tests, takes time. It adds delays to the latest release of the code being allowed out to the end user.
So if your end users are waiting for a new feature that will greatly improve their experience of an application and this new feature is delayed due to the release not getting past QA because they have to raise a bug for something that has broken in an existing part of the application. The end user will be disappointed, and a happy end user is what we all want.

Unit test coverage is important, it vastly improves the quality of an application, but if due to time constraints an application has been delivered without a high level of test coverage, it’s not the end of the world. By allowing developers to write tests for the existing code, the coverage will grow over time and the quality of the application can be guaranteed when a new feature is released to your happy users.

Writing good Pull Request descriptions

As developers, we like to get work done quickly. There is a feeling that if we finish fixing an issue or completing an issue as quickly as we can, then is obvious to the other team members, who may not be developers, that we are good at what we do because we get things done quickly.
This is dangerous, it can lead to bad practices slipping into your teams’ processes, where developers are trying to cut corners and get that Pull Request (where a developer asks the rest of the team to ‘pull’ their code into the main codebase of an app) ready as soon as possible.
One area where this cutting corners can happen is in PR (Pull Request) description messages, where the developer explains what this PR is about. If this is not completed then all the other member of the team who is reviewing the PR (where a second developer looks at the code changes made, and checks for any problems or can suggest ways that something might be done in a more efficient way), this second developer will just be shown a list of files, with the code changes highlighted.
From that, they need to work out what this PR is trying to either fix or add to the app’s codebase. Usually, without this context, the second developer will look at the changes, and think ‘well the syntax of the code looks fine, there are no obvious problems with how it’s written, I’ll Approve it’. Then this new PR is added to your app’s codebase, it all works and everything is fine.
But a few weeks later your users are complaining that the app has a strange issue when they use it. So you ask your developers to look into the cause of the problem. It could be due to something that has gone in the latest version of the app. So as any good developer should, they look through all the PR’s that went into that last release of the app.
This is where having a good description of what was done for a PR is so important. Yes, you can find a branch number that matches the list of the branches of code that went into a release, but if there is no description or no context of what work was completed as part of the PR, then it all becomes a guessing game.

So what goes into a good description?

There are a couple of things I think should go in a PR description:
1. Ticket number and title
2. A brief explanation of work completed
3. Bullet list of changes made

Adding a Ticket Number and Title

The title of a PR can have a lot of different variations, I’ve seen some places where the title is used to show a log of the changes made. From the PR’s in a release a log showing all the titles was used to show a report of what went into a release. This is helpful, but it meant that all the PR titles needed to be in a certain format and this format wasn’t particularly reading for humans.
Having the title of the ticket and the title number in the description as the first line makes it possible for a developer to see what was the corresponding ticket (if we’re using Jira) and what the name of the ticket was. Then the developer can search for that ticket and get an overview of what the PR was trying to do.

A brief explanation of work carried out

Next, I would add a brief, a few paragraphs, not an essay, an explanation of what work was carried out, what was added or fixed and how this was done. So someone could read this and get a sense of what was completed in the PR.
This doesn’t have to be too much, just enough so anyone knows what work was carried out.
A description is not only useful to other developers who may have to work on an old PR but also the original developer, to remind them of what they did for the PR.

Bullet list of changes

This is where you just list the changes you made. Maybe list each amended or new file and list what changes were made. Something like:

Add new sort function to account service
Removed commented out code from the interface
Add unit test for main login service

Along with the title, brief description and bullet list of changes it is clear what went into a PR. Making it easier for developers in a team to be able to see what went into a PR.

Some developers in your team might say that this is a was of time, and if you need an explanation of what some code does then it’s not well-written code, but I think that’s laziness on the developers’ side. No one’s code is that easy to read, especially after a few months. Having your developers follow the good practice of adding a description to any PR they make will no doubt help the team. The more the team know what’s been added to the code base the quicker a fix for an issue with an app can be fixed, the faster the fixed app can be released to your users.

If your team aren’t using descriptions in their Pull Request’s then maybe its time to ask them why, and if they say it takes to long then make sure this effort is included in the estimates they give. It’s work the time in the long run.

Principles of Writing Testable code

I’ve recently been spending time researching into how to write unit tests for an existing codebase. One thing that keeps coming up in the research I’m doing is how important it is to write testable code from the start, but what is testable code?

Well from the research I’ve been doing I found that to write testable code a good approach is following the SOLID principles.

S – Single Responsibility Principle
O – Open/Close Principle
L – Liskov Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle

So what do these principles mean and how do they apply to Angular?

Single Responsibility Principle is where an Object should do one thing and one thing only. For example in a controller or component you might have a function that loads some data, updates a local array then loads some more data from another source and finally displays this data in the UI. Well, that is four different things this one function is doing. To make this more testable it would be better to have one function that loads and returns data. One function that binds data passed into it to a local array, then another function which loads data from the second source and then finally allowing Angulars data binding to bind the data to the UI.

This means that you have only three separate functions, which can all be tested separately. One test to check the first function loads data correctly, a second test to check that the second function binds any data passed into it to the local array and finally the third test to check that the third function loads the data from the second source as expected.

Open/Close Principle is where a class is Open to extension, but Closed to changed. An example could be a function loads and returns some data. Then as the project continues the requirement for that data is changed as it is now ordered alphabetically. So you go back and amend the function to order the returned data after it has loaded. By doing this you’ve broken this principle. What you should really do it add a new function that calls the first function, then takes the returned data and then the second function performs the ordering of the returned data. This way you have two separate functions, both performing smaller tasks and the first function, which is already tested, has not been changed.

To write a function with this principle in mind, it needs to (in this loading data example) be able to return the loaded data and not just simply bind the returned data to a local variable or array. If the load data function returns the data as it loads it, then this allows other functions to take this returned data and extend what can be done with it.

Liskov Substitution Principle is where a class that uses another class, should be able to accept using another class without it knowing the difference. Within Angular, this means a controller or component may be using a service to load data, but the controller/component knows so little about the service that another service could replace the original one, without any changes needed to the controller/component.

This is an extremely important principle for writing testable code because adhering to this means that external services can be mocked in tests in order to write tests for just the function that uses this service. Through the use of mocking we can write tests that test different scenarios to see how our original function handles various responses from the mocked service.

Interface Segregation Principle this is important because it forces you to write smaller interfaces/classes which are easier to mock in tests. For example having a service that does loading data, aggregating data and ordering data, means that you will need to mock all three different functions in order to test something that is just using the loading data function. Separating it into three separate services means it is easy to mock just the one you need in order to test your code.

Dependency Inversion Principle is where your concretions (the act or process of concreting or becoming substantial; coalescence; solidification) or classes that are set out. Should only depend on classes that are abstractions of functionality. This means if you have a class that does something, like filtering an array. Then anything other classes it needs in order to perform this filtering should be an abstraction of the implementation. For example, with your class/function that filters an array, you may use something like Underscore or Lodash to help with the filtering. When you use Underscore or Lodash’s function you aren’t using the inner workings of the library, but an exposed function that abstracts away the inner workings of the library. So if in a new version of the library the helper function you are using is re-written to make it faster, as far as you are concerned you are still calling the helper function in the same way.

So by writing your code using this principle, you are writing more loosely coupled code, which is easier to test, because you test the individual parts. Parts that know nothing or need to know nothing about the inner workings of each other. This makes mocking for tests easier to do.

Following these principles will help make your code more modular, separated and therefore easier to mock for the tests you are going to write. From the research I’ve been doing the main concept to get in order to write more testable code is, in isolation, meaning writing code that can run in isolation is easier to test. It is easier to mock any dependencies (which there shouldn’t be many) it’s easier to write tests just for that single piece of code. Therefore writing more and more tests leads to an application which has more test coverage going forward.

Here are some links to articles, blog posts I’ve found during my research:

Theory of Uniting Testing in Angular

I recently finished reading through an article on Unit Testing in Angular. The article was from the Infragistics website and in 3 parts it tried to demystify Unit Tests in Angular:

In this article, the author, Jared Fineman, really goes into how to setup your tests, how to structure tests and some of the great new features of Angular, that help with testing. One great point Jared makes is *In the world of development, unit tests have long been viewed as second-class citizens. * This is very true, it is something I have been guilty of too, forgetting that Unit Tests are an extremely important part of the development process. As part of my drive this year to improve the quality of my work, I’m focusing on both Unit Testing and readability, so I need to make writing test a core part of my development process.

In the first part of the article, Jared shows how to set up tests for your project. Though at the time of writing this version 6 of Angular was not released yet. So there is a section about updating the .angular-cli.json file, which has now been replaced by the angular.json file. Then in the other two parts of the article, Jared goes through structuring unit tests and some of the great features that Angular has that allow you to really explore the inner workings of your components. So you can write tests that examine all parts of the component.

The one that struck me in the second part of this article was the approach he mentions for structuring your unit tests. He mentions this AAA approach, which stands for Arrange, Act and Assert. The idea is that you first setup everything needed to run the component that is going to be tested, you basically arrange all the parts needed for the component. This could be modules that need to initialised, other parent components or mock data.
Next is the Act section, this is where you call the method or the component to be tested and from that call, the result can be examined. Finally, there is the Assert phase, where our assertions or expectations are tested.

This AAA methodology is great for learning how to set up tests, it is definitely something that isn’t documented enough in the official Angular docs. If a developer is new to Angular and they want to start writing tests for their app, the Angular docs do give a detailed overview of how to write a test for different scenarios. The new Angular docs really give a lot of examples, how to test components, how to test the DOM, how to test services and providers, but the theory of unit testing is not discussed enough in the documentation (but the Angular docs is open source, so maybe that can be changed).

There is, of course, articles about AAA outside of Angular, here are a few I found, though they are C# based the theory still applies:

There are a lot of articles about the Theory of Unit Testing, just not all Angular specific. It is worth searching around for them. This article from Jared Fineman is a great start.

When enough is enough,

There is a time when writing code that you need to say to yourself, enough is enough. I’m not talking about giving up coding, what I’m talking about is when you’ve been adding so many features to a section, that the code is unmanageable. There is a point where cramming in another feature to a section, means that the code behind will need to be re-written in order to make it easier to read, easier to manage and easier to test.

One of the big problems with AnglarJS, when it first became popular was developers didn’t know the best practices for how to write good clean AngularJS applications. The main problem was with the controller. The controller is a great concept, having a JavaScript file that sits behind your HTML template, which has access to all the elements in the template was amazing, but soon developers started to go crazy writing everything in one controller, at the time there wasn’t a ‘style guide’ that showed us a better way. Slowly over time, better practices were shared in the community, there were more examples of how to structure our AngularJS apps.

Recently I’ve had to work with an AngularJS project that has a controller where the structure of the controller has become unmanageable. Currently, the file has over 1200 lines of code, it is full of functions all doing different things, nothing grouped together in a logical structure, the use of both $scope and VM models is throughout the file instead of using one approach consistently. It is hard to work with this controller, and it is important of the functionality of the application.

Now I can see how this controller has gotten into this situation. It’s clear that at the beginning of the development this core piece of functionality that the controller manages was not fully planned. So the developer probably thought, this section doesn’t have a great deal of functionality I can keep it all within one controller.
Soon the features for this section grew and became more and more complex, the demand to get them delivered also grew, so the time for refactoring was not available. Now we are in a situation when we have a 1200 line controller that is hard to work with, nearly impossible to add new features too and is still buggy.

In order to stop this type of situation, developers need to be able to say to the PMs and stakeholders of a project, that they need to spend some time, refactoring the existing code in order to make it so new features can be added easily.

When a team successfully uses Scrum there is this time to raise issues like this, to let the PMs know that a bit of time is needed in order to tidy up the code before tackling a new feature. As part of the standard sprint planning, this can be raised. Without it the team just keep ploughing on building onto of existing code, adding feature after feature until everything is nearly unmanageable.

So what can developers and teams do in order to stop this happening:

Have regular sprint planning meetings to discuss the work coming up and not keep ploughing along without reviewing
Set out from the beginning a style guide, how the team will approach the development of the application
In PR reviews, don’t just have a quick look over the code and accept it, discuss with the developer if there are problems or code smells and how they can restructure their code to avoid these types issues later
Teach the more junior developers good practices on structuring code
Tell the managers and stakeholders why having good code quality is important to their project, why cutting corners, will only come back to haunt a project later on

Unit Testing and tight timescales

I’ve worked on a number of projects, where we’ve started the project with the idea to have 100% coverage with unit tests, but as soon as deadlines start to get closer, unit tests are the first to go.

What are the reasons for this?

There are several reasons why this happens, as the deadline for a project gets closer, you’re developers are put under more pressure to get all the features completed. So they need to focus on that, the time spent on updating or creating new Unit Tests is then spent on getting these features delivered.

If the project being developed in an internal project, and the stakeholder sees that the release deadline is getting closer, they are probably wondering why their developers are spending time writing tests and not being that new feature they have just asked for. I’ve seen this several times, the project manager or business owner, is under pressure to deliver and they hear a lot of talk from developers saying they need to write the tests for a feature, but to the PM that seems a waste of time. On one project we were asked to stop developing unit tests as we needed to get a version of the website ‘out the door’.

I’ve also been on projects where, as a team, it was decided to ‘come back and write the tests later’. As an approach to getting this high level of quality that the project needed. This wasn’t a good idea, as we never went back to write the tests and eventually the code coverage on the project was very poor.

Unit tests and test coverage are sometimes seen as nice things to have. We know as good developers we should have them, we should have tests for every line of code we write. There are many talks, books, podcasts, where ‘experts’ are telling us, developers, that you should be writing tests. It’s like when you are trying to eat healthily, you know you should make a salad for lunch, but those crisps and cheese rolls are just so much easier and quicker to make.

How can this problem be solved?

The central cause of this problem is time, projects basically run out of time to get all the features of a project completed and still write the tests. One solution to this problem is better planning up front. When scoping out a feature, developers need to see unit testing as an integral part of the development process. If they are using the points system in scrum to say what the effort involved in creating a new feature. Writing the unit tests needs to be considered as part of this effort and it is up to the senior members of the team to remind all the developers to include this unit test development as part of their estimates of effort.

Developers need to also show the Project Managers and stakeholders the importance of maintaining good test coverage is to not only to the project as it is now, but a year or two down the line, when a new feature of the site/app is going to be added to the project. When these new changes start to be developed for the project, the PM/stakeholder needs to know how important it is to have good tests during this ‘adding a new feature’ development phase is, in order to make sure the existing site/app doesn’t have bugs introduced.

As well as developers not adding the effort required to their scrum estimates, and PMs not aware of the importance of keeping tests up to date in a project, another issue is that writing test does take a long time, especially if you are just starting out writing tests. I’ve worked on projects where when I was writing my unit tests I wasn’t convinced that the tests I was writing were actually ‘testing’ my code, but was probably just checking that a value is present. The quality of the tests was not very good..

As developers, we are shown all about the features of a new framework or library, how it does the new latest thing, how fast it runs and how it is better than framework X, but it is very little in the framework documentation on how to plan your tests? What approach should developers take when writing tests? We see many examples where a test suite is set up, and the test checks the value of a <span> in a template, or a test for an HTTP request of a static file, but there isn’t much information about the ‘theory’ of writing good unit tests. Have you tried writing tests for AngularJS directives? It’s easy to check the HTML of a directive, but testing the inner workings of your directive? Nearly impossible.

If developers spend the time learning about writing tests, and if the authors of these frameworks/libraries show others how to write good tests for their framework based apps. The time developers spend writing tests will be reduced. The more we practice something, the quicker and better we get.

If PMs and stakeholders can see unit tests and coverage as an investment into ensuring the quality of a project and the providing long-term support to a project, they will allow the developers to spend this extra time need to write tests.