Category:

programming

write tests or don't but read this
flutterprogrammingsoftware engineering

Write Tests or don’t, But read this – Flutter Testing

by easazade
written by easazade 7 minutes read

Writing tests can save you a lot of headaches. There are a lot of articles and youtube videos out there about why you should write tests. But have you ever wondered why many developers don’t write tests?

Ok, We’re not going to talk about what you’ll miss or what problems you’ll face if you don’t write tests. I think there is enough content about it out there. Instead, we will talk about the reasons why some developers do not write tests for their software, even though many admit that writing tests is a good practice.

How important is it?

Not writing tests is a serious issue. A lot of money is lost because of this issue in the software industry. Developers lose their credibility or even jobs because they didn’t write tests for the codes they delivered. There can be unsatisfied users. There can be lawsuits and legal troubles just because of a simple mistake or bug that could have been avoided by writing tests. So for sure, Not writing tests is an important issue and worth diving into to figure out why it happens.

I strongly believe if developers realize the issues not writing tests can lead to, many of the reasons that compelled them not to write tests won’t be strong enough to do that anymore. We will discuss some of the reasons behind this issue, So read on.

Not knowing the How

There are many developers that really don’t know how to write tests. They write them, But they don’t know how to write them. If you want to write flutter tests, you need to check out Flutter testing documentation. Flutter framework provides 3 ways of testing, unit test, widget test, and integration test. Each one has its pros and cons. I’d say the docs on Flutter testing are pretty good, But That doesn’t teach you how to write good tests.

Think about automated tests for a few seconds. You want to write code that tests another code’s behavior. Whether it behaves as expected or not. Let’s talk about it with a simple example. Let’s say you have a single unit (class, function, etc), and you want to make sure it works fine. You write 6 tests to cover different scenarios. Great, Now you want to make a small change in your unit, and suddenly all your tests show a syntax error. These tests are called broken tests. Now you have to go refactor the tests again. Here is the thing you need to know about how to write tests.

You need to write your code in a way so that your tests will break less often, and if they are broken, they take much less of your time to refactor them. If broken tests and refactoring them bother you, you’re probably doing something wrong.

So what is it that developers should know?

In short, when writing code, you should also think about how you should test it. It’s called writing testable code. You can try to improve the testability of your code by following the SOLID principle and writing your units as loosely coupled as possible. My suggestion to you would be to think about the testability of your software as you want to write it or Do TDD, for which you should write the test first and then implement the actual unit those unit tests are written for.

When you’re looking at testable software, it should be like a good car when you pop the hood. When you look under the hood, you see different parts connected together through wires and tubes. Even though these parts work together, they are not tightly coupled together. You can remove a part if you think there is a problem with it. Run some tests on it in isolation and find the problem and fix it. You don’t have to dismantle the whole car in order to replace a part or isolate it from other and test it. This is all possible because these parts and components are loosely coupled.

Not knowing the Why

If there are developers that don’t know how to write tests, then I would argue that there are definitely developers that don’t know why they should write them.

There are developers that truly don’t know why they should write tests. If you talk to them about writing tests, they agree and admit it is a good practice. And some of these developers even practice what they say. Yes, some developers write tests just because everyone else is doing it, and it is a good practice. And there are people that are very honest with themselves and think, if I see no reason to write tests, why should I write tests?

Not knowing why is not a good enough reason to forsake writing tests for good. While knowing why you should write that test is a must. (Well, I guess you should know why you’re doing what you’re doing in life as a general rule). But if there are many fellow developers out there doing something, you should at least figure out why they are doing that. If you figured out the reason and still don’t want to do it, that is respectable. There is a saying where I come from which says

Not Knowing isn’t a bad thing, But not asking is one

Not feeling the Why

This may sound like the above argument, but it isn’t. Sometimes developers know exactly what they should write tests, but they don’t. And it isn’t because of laziness or being irresponsible or anything. It’s just because they haven’t felt the pain of the issues it can cause. Some will feel those painful moments, like when you created a local database for your Flutter app and didn’t write tests for it, and it caused a series of annoying bugs that tortured you during the course of development. Or when you messed it up big time in your company and lost your credibility. Think about that moment when you wished you had written tests for your app. Or when you finally did write those tests, you wished you would have started writing tests sooner. The moment that made you feel the importance of WHY you should write tests.

Limitations of the framework or language

Sometimes the framework or stack we’re working with makes it hard for us to test the code we are writing in that framework/stack. In Flutter, if you’re writing unit tests and widget tests, it is very simple to do that. However, if you’re creating a plugin and you want to write tests for that, that can be somewhat challenging. If writing tests for your code is hard and challenging, it would be a compelling reason not to write those tests.

Not Knowing the When

There are projects where you want to write tests, but you don’t want to fully cover all units and scenarios. And that can be reasonable based on your software and its components and units. But there are parts of your software that, if it doesn’t behave as it is supposed to do (bug), Will cost you a lot. For example, if you’re creating a wallet feature for your user, that is when a feature needs to be fully tested both on the backend and front end. Because if bugs happen here, this is gonna cost you a lot. You may even get into legal problems.

Bad Experiences in the Past with writing tests

Sometimes in life, we have bad experiences in the past that will shape how we perceive things in our life and make decisions. Programming is not different. If in the past you didn’t know how to write tests, you probably had bad experiences with software testing. Hence in the future, you may avoid writing tests because you don’t find it helpful for your project, which will also slow you down.

Not realizing the damage it can cause

This is a very important one if you realize the damage it can cause to either the business/client or even to you. You can lose your credibility, or the business or client could lose their credibility, especially in this competitive market. Bugs, in the best-case scenario, will worsen User experience, which is still a bad thing. In worst-case scenarios, you could cause you’re company or client to lose users, money, resources, opportunities, stock shares, and so forth.

Your code is your reputation

Being lazy and irresponsible

I don’t see that I need to explain much here. If you care about the value of the code you deliver and how it may affect others and their lives or livelihood, you should write tests when needed.

Not given the opportunity

Ok, it’s not always the developers’ fault. Sometimes you’re going to work on legacy code or some software that has very low testability. Just because it was developed that way without any tests, and now in order to write tests for that software, you have to refactor and rewrite the whole thing. And sometimes, in these cases, companies, based on good/bad decisions, decide that the cost of dealing with bugs in production is less than refactoring the software. So they decide not to do anything about it. So the developers continue maintaining and developing the software without writing any tests.

your flutter state management makes no
dartflutterprogrammingsoftware engineering

This is why your flutter state management makes no sense – part 2

by easazade
written by easazade 9 minutes read

In part 1 of this series, we discussed how many of the problems we face in our flutter state management are actually from how we define our state And that these problems usually start when our state gets bigger and bigger. This section will discuss what issues will appear in our flutter state management when breaking a state into smaller ones.

Let’s continue where we left off

If you haven’t read part 1, make sure you go and read that part first.

In the last part, our example of a single page of an app evolved into something bigger. We started with a simple page, then in the course of 3 iterations of changes, the page became more complex, and so did the state management unit that populated the page. Below you can see our page.

Above, we have our user profile screen. A screen where the user’s profile image is shown and can be changed. There are also two lists of posts and pictures. And each time a new tag is selected from the tag section, posts, and images relevant to the selected tag will be loaded.

Below is the state class we use for our flutter state management unit (imagine Bloc, for example). It’s big and a mess.

class UserState {
  final UserProfile profile;
  final Tag selectedTag; // new property
  final List<Post> posts;
  final List<String> images; // new property
  final bool isLoading;
  final bool isLoadingAvatar;
  final bool isLoadingPosts; // new property
  final bool isLoadingImages; // new property
  final Error error;
  final Error postsError; // new property
  final Error imagesError; // new property

  UserState(...);
}

// tags shown in screen are read from profile.tags

Separating flutter state management units into multiple ones

Ok, we decided to fix the mess we made above, And one of the most common ways is to separate the state into smaller ones. which also means separating our logic into smaller units. If we are using Bloc, then we will have multiple blocs. Let’s see how it will turn out. 

class UserState {
  final UserProfile profile;
  final Tag selectedTag;
  final bool isLoading;
  final bool isLoadingAvatar;
  final Error error;


  UserState(...);
}

class UserPostsState{
  final List<Post> posts;
  final bool isLoading;
  final Error error;

  UserPostsState(...);
}

class UserImagesState{
  final List<String> images;
  final bool isLoading;
  final Error error;

  UserImagesState(...);
}

Was that a solution or just a new problem?

Was separating states and the logic that manipulates and manages that state into multiple classes fixed our problem? Or did we trade our problems for new ones? If you look at the code above, we fixed our problem. The problem was that we had a state object that, when someone would have looked at it, would have made no sense. It was hardly readable and understandable. But at what cost? Let’s see what problems we might have caused by separating our state like this.

Did it make sense to separate it logic-wise?

Ok, We separated the Bloc into multiple blocs because our state was big and unreadable. Ok, we solved the problem of readability. But if we look at our Bloc from the business logic perspective, did it make sense to break this Bloc into multiple blocs? In some cases, it might make sense, and in others, it doesn’t make sense to separate the state and the logic that manipulates that state into multiple units. This will introduce more complexity and can even make the code more unreadable in some other parts, like the UI or our test code. In that case, our first attempt to improve our blocs’ readability has decreased our code’s readability in other places.

Logic code is a mess

We have separated our state into three Blocs, UserBloc, UserPostsBloc, and UserImagesBloc. Even though our states are now separated, the logic that manages them still depends on other states. In our case, we need to know what tag is selected in UserBloc to fetch relevant posts and images from the backend server and update the UserPostsState and UserImagesState. So that makes our blocs tightly coupled.

We also need to write extra codes in our blocs so they can listen to each other. And if the dependency graph between them is complex and there is no way we can make it simpler, the communication between them will also be complex.

Wait, didn’t separating the state supposed to solve this mess? How did we get into a more considerable lot?!!!

Test code is a mess too

We have made three blocs out of one Bloc. If our entire app was going to be just one Bloc turned into three, we could have gotten away with it. But what if it was ten blocs separated into thirty blocs? Without a doubt, we need to write more tests. But it doesn’t end there. Since many of our blocs will depend on each other, we will want to have some tests that test them against each other. Testing how they react against each other. This second issue will result not only in more tests but also in more complex tests.

Also, tests are meant to be readable. If your colleague is reviewing your code and reading the tests you wrote to see how things are supposed to work, or a new developer joins the team, They will have difficulty reading those tests. Also, it will take more of their Time. And let’s mention that this would add to all the excuses developers use not to write tests.

Remember, we said the point we are referring to is that poorly defined states will waste development time. Well, Time being wasted will not be our only problem. Because when we change our states too often and too much, our tests will brake too often. And that will also cost development time, of course. But when tests brake too much and too often, At some point, developers will stop writing tests.

Our UI code is a mess too !!!?

The UI code needs to be updated as well. Because We need to build our UserProfilePage from three blocs instead of one, our UserProfilePage code will probably look like this.

class UserProfilePage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: ListView(
        children:[
          BlocBuilder<UserBloc, UserState>(
            builder: (context, state) => ProfileSection(...),
          ),
          BlocBuilder<UserPostsBloc, UserPostsState>(
            builder: (context, state) => PostsSection(...),
          ),
          BlocBuilder<UserImagesBloc, UserImagesState>(
            builder: (context, state) => ImagesSection(...),
          ),
        ],
      ),
    );
  }
}

In our example, the code will be as clean as above. It is clean. But could it have been a mess?

What if we needed to process data from all three states to get the data required to be shown on our screen? What would our code look like?

In the best-case scenario, that part of our code would have been like

// insde the build method of UserProfilePage
MultiBlocBuilder(
    blocs: [userBloc, userPostsBloc, userImagesBloc],
    builder: (context, states) {
        final userState = states.get<UserState>();
        final userPostsState = states.get<UserPostsState>();
        final userImagesState = states.get<UserImagesState>();
        
        final someData = _processData(userState, userPostsState, userImagesState);
        
        return SomeWidget(someData);
    }
),
.
.

In the worst-case scenario, that part of our code would have been like

// insde the build method of UserProfilePage
MultiBlocBuilder(
    blocs: [userBloc, userPostsBloc, userImagesBloc],
    builder: (context, states) {
        final userState = states.get<UserState>();
        final userPostsState = states.get<UserPostsState>();
        final userImagesState = states.get<UserImagesState>();
        
        if(userState.isDoingThis){
          return SomeWidget(
            child: Text('some text'),
          );
        }else if(userState.isDoingSomethingElse && userPostsState.isLoading){
          return SomeOtherWidget(
            child: Item(
              padding: const EdgeInsets.all(24),
              item: ...
              .
              .
            ),
          );
        }else if(userImagesState.hasError && userState.selectedTag != null){
          if(isThis){
            return ThisWidtet(
              padding: const EdgeInsets.all(24),
              item: ...
              .
              .
            );
            
          } else if(isThat){
            return ThatWidget(
              padding: const EdgeInsets.all(24),
              item: ...
              .
              .
            );
          } else{
            return SomethingDifferent(
              padding: const EdgeInsets.all(24),
              item: ...
              .
              .
            );
          }
        }
    }
),
.
.

Take a look at the above example. We have some complex logic code to process the data that must be shown on our page. This convoluted logic could have been encapsulated within our flutter state management if we had only one instead of three. This logic code leaks inside our UI simply because our states are defined poorly.

Move the logic out of the UI

One of the points of having a class (unit) to manage our state is to avoid writing logic code in our UI layer as much as possible. But in the above example, we are failing to do that. The solution to the above mess is simple. Move the logic code to another unit. We can move the code written above to one of our state management units that makes sense, but what if it doesn’t make sense to move the code to any of them ???

Ok, we know we don’t want our logic code mixed with our UI code, And we know that we can’t move them to any of the three blocs we defined above because it doesn’t make sense. So the only other options are either to leave the mess be or to create another bloc to process the data we need, and We build UserProfilePage from that Bloc. Let’s see the code for that Bloc. 

class UserProfileBloc extends Cubit<UserProfile> {
  CounterCubit(
    this.userBloc,
    this.userPostsBloc,
    this.userImagesBloc,
  ) : super(UserProfile()) {
  
    [userBloc, userPostsBloc, userImagesBloc].listenAll(state1, state2, state3) {
      // calcualte the new state and update state !!!
    }
  }
  
  final UserBloc userbloc;
  final UserPostsBloc userPostsBloc;
  final UserImagesBloc userImagesBloc;

}

Too many blocs in on page

We have removed our logic code from our UI code, But now we use four blocs in our page. If we could find a way to combine some of these blocs, it would have been much cleaner, hmm. Well, we just did that in UserProfileBloc. What if we could listen to our other three blocs in UserProfileBloc and process the state of those three blocs? Then we need UserPorifleBloc to build the UserProfilePage. Let’s update the state for UserProfileBloc first.

class UserProfileState {
  final UserProfile profile;
  final Tag selectedTag;
  final List<Post> posts;
  final List<String> images;
  final bool isLoading;
  final bool isLoadingAvatar;
  final bool isLoadingPosts;
  final bool isLoadingImages;
  final Error error;
  final Error postsError;
  final Error imagesError;

  UserProfileState(...);
}

Wait, What?!!! We are back at square one. You may think, Ok, there is no way I make this mistake. But many of us do. Because the codes we wrote above are not created in one day, It is developed over several iterations of changes during the development process.

Don’t miss the point

Separating the states is not always a wrong solution. The chances that you simultaneously hit all or none of the problems explained above are low. But when they appear in your project, they’re not going anywhere until you deal with them. Of course, if you put in enough time, you can figure out how to make it work and eliminate said problems while your logic code still makes sense. But should you? The point is you’re still wasting your time on something that shouldn’t require this much Time. Remember, in the software industry, wasting Time is wasting money.

your flutter state management makes no
dartflutterprogrammingsoftware engineering

This is why your flutter state management makes no sense – part 1

by easazade
written by easazade 7 minutes read

Flutter state management. Let’s talk about why sometimes you think something is wrong in your state management, But you can’t really tell what it is. Like those times when your state gets complex. And you can’t really find a way to make it more readable. You think to yourself; this code should be more clear. But you can’t really figure out how to make the code more clear in a way that it still makes sense.

State management patterns are the same

When it comes to flutter state management, there are many options out there. Riverpod, Bloc & Mobx are some of the popular ones out there. But we are not going to talk about any of them. Because they are not the problem. Of course, all of them have their pros and cons, But They all get the job done. And the job is to hold your state and notify the listeners whenever you change that state. The problem that we are talking about is the one that almost always exists no matter which Flutter state management library we use.

State Definition is the problem

So what is the problem if flutter state management solutions out there are not the problem? There might be other kinds of problems, But in this post, we are referring to the state definition problem. The way we define our state is the single cause for most of the problems we face in flutter state management. Let’s talk about it in an example.

This is something I have seen in a lot of projects. At first, we define a state management unit like Bloc, Store, or even a ChangeNotifier. It doesn’t matter which one we use because they are not our problem. So we have a small state with a few properties in it. Everything looks good and works fine. Then as we develop our flutter app, we start changing our state, adding more and more properties to it. Making it bigger and bigger. It’s not necessarily bad to have a big state unless it’s confusing and not readable. At this point, maybe it is wise to separate our state management unit into smaller state management units. Everything’s still fine. No problem.

Until it doesn’t make sense

But there are times when things just don’t make sense to you. I’m specifically talking about those times that you are sitting on your chair staring at your screen and thinking to yourself, “How should I change the state definition of my bloc (Store or anything else) so it can reflect the new piece of data I want to show on screen, WHILE the code, is still clean and readable”. I’m not saying that you won’t solve the problem.

In the best-case scenario, you will come up with a way to update the state definition while the code is still readable. In the worst-case scenario, you will update the state you defined, but the code is just bad. Either way, you have put time and energy into something that should not have required that much time and energy. And you’re most likely going to do that again when you’re updating that state definition again. Now that is just time and money wasted.

Now even though I have just started explaining the problem and have not exactly made you feel and realize the problem, you may be asking what exactly is wrong with the way we define our state. That is something I will tell you at the end of this series of posts. Right after, I have shown you many of the different problems caused by bad state definitions.

Let’s see the problem in code

We are going to see step by step what these problems are. And then, we are going to see how solutions that are usually used to solve these problems will introduce new problems. At the end, we are going to talk about the real reason why none of these solutions work.

Take a look at the images above. You can see 3 different states of a single screen. We have a user profile screen that shows the user’s avatar at the top and his/her posts below. image 2 shows how our screen looks when the app is getting data from the server. in image 3. We want to define a state management unit that populates data on this screen. Here is what the defined state for that state management unit would look like.

For the sake of not making this article long, we are keeping scenarios and code simple. We’re just gonna see the complexity of the defined state over iterations of change.

class UserState {
  final UserProfile profile;
  final List<Post> posts;
  final bool isLoading;
  final Error error;

  UserState(...);
}

We use profile and posts properties to show the data on the user profile screen. We use isLoading flag to determine if the screen is loading and if there was an error. This defined state will cover all our needs in the above screen for now. So everything is fine for now.

Let’s Add more things to our screen

Ok, we’ve developed and completed our screen and the state management unit used for it. After some time, the design of the user profile screen has been updated. And now, we need to implement the new design.

In image 4, we see that an edit button has been added to our design that allows editing profile images. and in image 5, we see that the user profile screen shows a loader indicator when a new image is being uploaded as the user’s avatar. Now let’s see how our code for our state object will change to implement a new design.

class UserState {
  final UserProfile profile;
  final List<Post> posts;
  final bool isLoading;
  final bool isLoadingAvatar; // new property
  final Error error;

  UserState(...);
}

We just added a new property isAvatarLoading flag, to show the loading on avatar image because we can’t use isLoading flag for that, of course. Everything’s still fine. you might look at the code, and it might annoy you just a tiny bit. But you just leave it at that.

Let’s Change the screen even more

We have a new design for our screen that we need to implement. This is a little bit more complex than the previous design. we load tags from the UserProfile object in our state on screen. Then each time a user selects a tag, the relevant posts and images for tags will be fetched from the server and shown on the screen. In image 7, we see that the shimmer effect is shown when we are fetching relevant posts and images for the selected tag. In image 8, we see that if there was an error during fetching posts and images for the selected tag screen shows a try again button.

Now let’s see how our code for our state object will change to implement the new design

class UserState {
  final UserProfile profile;
  final Tag selectedTag; // new property
  final List<Post> posts;
  final List<String> images; // new property
  final bool isLoading;
  final bool isLoadingAvatar;
  final bool isLoadingPosts; // new property
  final bool isLoadingImages; // new property
  final Error error;
  final Error postsError; // new property
  final Error imagesError; // new property

  UserState(...);
}

// tags shown in screen are read from profile.tags

At this moment, you’re gonna think. Ok, this is getting out of hand. Many of us will see the above code and think this code is really bad. And you come up with solutions like converting the state management unit (Bloc, for example) into multiple ones so you can separate the state and avoid this mess. Or some of us may think, let’s define the state using a Union or Sealed class. It may work in some situations, But they will introduce limitations and problems of their own.

Some of us may say I know how to fix this. But if we are still wasting a lot of time each time we want to change how our states are defined, I say that is not a solution to this problem; that is just a new problem. Creating problems after problems to be solved wastes a lot of time & energy that should have been put elsewhere.

In the next part, we will talk about…

Here we just talked about how states can be big and messy. In the next part, we will talk about how solutions that are used to solve this mess are just new problems.

future of programming
programmingsoftware engineering

Future of programming (Interface problem)

by easazade
written by easazade 4 minutes read

Future of programming is not written, just like no future is. But it will be shaped and created how we want it to be. What is interface problem and how solving it will change the future of programming. Let’s talk about that.

Interfacing with machines

We use many digital devices everyday like our phones, laptops, ATMs, car infotainment and so on. The way we communicate to these machines is called interfacing. There are different ways we interface with machines. Through touch for example. We use gestures like tapping, scrolling and swiping, we write texts, we use mechanical buttons and Sometimes we use voice commands. there are other ways of interfacing as well but the thing is they are slow compared to what ways we could interface with machines. Like using our thoughts instead of our thumbs.

Interfacing is a little different for programmers

Programmers write text to explain their ideas of how a program should be to the computer. When we write code, we think about what we want different components of a software to do then we put it into code. We lose a lot of time putting our thoughts into code. The entire programming is based on this approach to use writings (code) to explain our purpose to a machine. Hence we have programming languages that are text based.

Other ways of Interfacing for creating a software

Some may say this is a good approach. I think it’s the best approach we have right now. But we all know it’s a slow process to interface with a machine through code (text). And because of this problem (slowness), there were other solutions or attempts to make this process faster by going away from interfacing through code (or text). This is why we have WYSIWYG services. There are services like website and application builders that allow developers to ui elements to interface with the machine and communicate their thoughts on how that application should be. But these services are not fixing the problems, they’re using a different type of interfacing which is still not directly communicating the developer’s thoughts to the machine.

It’s fair to say that WYSIWYG services have their own problems. They have their use but they are much much less reliable than programming languages.

Interfacing directly

By Direct interface I mean we think and the machine interprets that. We don’t need to learn a language to speak to the machines. And they don’t need to learn our language to understand what we want. We just interface with them through our thoughts directly. Thoughts are much faster than writing code. Of course it will not just revolutionize programming but also our daily use of machines. we may no longer need keyboards or touchpads and touchscreens anymore.

Let’s even go further

Imagine if you could directly interface with an AI. but not in a way that only the AI can understand your thought but you can understand AI as well. Both your thoughts will be in sync. Imagine the power we’ll have to create or do anything. We will have 10 times the power and ability to create and achieve what we can achieve today. Software ideas can be implemented in a fraction of what costs us today. Many development problems that we have right now will not exist anymore and The world will certainly progress much faster.

Final words

We will make the Future. Our thoughts and imaginations will create the Future of programming. In this post I only talked about how solving a single problem will revolutionize programming. But there are many other problems to be fixed and many other ideas to be implemented. Write in the comments what you think the Future of programming would be like