Forem: Touré Holder

Should one get good at test-last development before learning TDD?

Touré Holder — Wed, 22 Sep 2021 00:43:19 +0000

I'd been writing tests for a while in a test-last development manner before learning how to develop software using the test-driven technique.

I find that many developers feel daunted by the practice of writing failing tests before writing the implementation/production code to make the tests pass, especially when they have little or no experience writing tests at all.

Since I can't go back in time and learn software testing using a test-driven development approach, I honestly don't know what it feels like and have thus decided to elicit the opinion of the community :)

Do you think it's better to introduce someone with no test writing experience to the practice of software testing with TDD right off the bat? Or is it better to learn TDD after becoming familiar with test-last development?

Creating adaptive layouts with Flutter

Touré Holder — Fri, 02 Jul 2021 11:39:55 +0000

In this tutorial you'll learn how to easily make a UI layout for your flutter app that adapts to different screen sizes with the adaptive_layout package.

The next few sections show how to build a simple UI that displays a list of movie posters and titles and allows the user to see more details of the movie when they tap an item in the list.

Small screen UI

On small, phone-sized, screens when the user taps an item they will navigate to a different screen with the details.

Large screen UI

On large screens, when the user taps a list item the details are displayed on the right side of the list and there is no navigation.

Live demo

Even better than an image, see a live demo of what we'll be building.

Let's go!

We'll take care of the behavior expected for small screens first, then adapt our implementation for larger screens. These are the steps:

1. Create a new app
2. Provide the data set
3. Create the model
4. Create the movie list page
5. Create the movie detail page
6. Navigate to the detail screen when an item is tapped
7. Convert movie list page into home page
8. Make the home page adaptive with the adaptive_layout package
9. Display the detail view when an item is tapped on large screens
BONUS: Make it look a little better on large screens
BONUS: Tests

1. Create a new app

Go ahead and create a new flutter app.

flutter create adaptive_layout_example

2. Provide the data set

We'll be using a hard-coded data set, so we can focus our efforts on the UI layout.

Under the lib folder, create a folder called data with a file named data.dart.
Copy the contents of this file into your file.

See the changes

3. Create the model

Create a Movie class with a static function that parses the data into a list of Movies and returns the list.

Under the lib folder, create a folder called model with a file movie.dart.
Paste the following content into the file.

import '../data/data.dart';

class Movie {
  final int id;
  final String title;
  final String overview;
  final String posterPath;

  Movie({
    required this.id,
    required this.title,
    required this.overview,
    required this.posterPath,
  });

  static List<Movie> getList() => data
      .map(
        (element) => Movie(
          id: element['id'],
          title: element['title'],
          overview: element['overview'],
          posterPath: element['poster_path'],
        ),
      )
      .toList();
}

const String LARGE_POSTER_BASE_URL = "https://image.tmdb.org/t/p/w300";
const String SMALL_POSTER_BASE_URL = "https://image.tmdb.org/t/p/w92";

See the changes

4. Create the movie list page

Now let's create a page that will display the list of movies:

Create a new folder under lib called pages.
Within the pages folder create a file named movie_list_page.dart.
In movie_list_page.dart create two StatelessWidgets: one called MovieListPage and another called MovieListView, with this content.

class MovieListPage extends StatelessWidget {
  const MovieListPage({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    final movies = Movie.getList();

    return Scaffold(
      appBar: AppBar(
        title: Text('Movies'),
      ),
      body: MovieListView(
        movies: movies,
        onTapItem: (Movie movie) {
          // TODO: Navigate to detail screen
        },
      ),
    );
  }
}

class MovieListView extends StatelessWidget {
  final List<Movie> movies;
  final Function(Movie) onTapItem;

  const MovieListView({
    Key? key,
    required this.movies,
    required this.onTapItem,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return ListView.builder(
      itemCount: movies.length,
      itemBuilder: (context, index) {
        final movie = movies[index];
        return ListTile(
          key: Key('list_item_$index'),
          leading: Image.network(SMALL_POSTER_BASE_URL + movie.posterPath),
          title: Text('${movie.title}'),
          contentPadding: EdgeInsets.all(12.0),
          onTap: () {
            onTapItem.call(movie);
          },
        );
      },
    );
  }
}

Observe that MovieListPage is a container widget for the presentational MovieListView widget.

Now, remove the framework generated MyHomePage and _MyHomePageState classes from lib/main.dart and use MovieListPage() as the home widget for the MaterialApp. The lib/main.dart file should now look like this:

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Adaptive Layout Tutorial',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      // Use `MovieListPage()` as the `home` widget
      home: MovieListPage(),
    );
  }
}

The list page should now be displayed when the app starts:

See the changes

5. Create the movie detail page

Now let's create a page that will display more details of a given movie:

Within the pages folder create a file named movie_detail_page.dart.
Similarly, in movie_detail_page.dart create two StatelessWidgets: a container widget called MovieDetailPage and a presentational MovieDetailView widget, with this content:

class MovieDetailPage extends StatelessWidget {
  final Movie movie;

  const MovieDetailPage(
    this.movie, {
    Key? key,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(),
      body: MovieDetailView(movie),
    );
  }
}

class MovieDetailView extends StatelessWidget {
  final Movie movie;

  const MovieDetailView(
    this.movie, {
    Key? key,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return SingleChildScrollView(
      padding: EdgeInsets.all(24.0),
      child: Column(
        crossAxisAlignment: CrossAxisAlignment.center,
        children: [
          ClipRRect(
            borderRadius: BorderRadius.circular(10.0),
            child: Image.network(LARGE_POSTER_BASE_URL + movie.posterPath),
          ),
          SizedBox(height: 24.0),
          Text(
            movie.title,
            style: Theme.of(context).textTheme.headline4,
            textAlign: TextAlign.center,
          ),
          SizedBox(height: 24.0),
          Text(
            movie.overview,
            style: Theme.of(context).textTheme.subtitle1,
            textAlign: TextAlign.center,
          ),
        ],
      ),
    );
  }
}

For simplicity, we are just displaying the poster image, title and overview of the movie in the detail view.

See the changes

6. Navigate to the detail screen when an item is tapped

Update the onTapItem() callback of the MovieListView in the MovieListPage widget, so we can navigate to the detail screen and back.

// Within the `MovieListPage` widget
onTapItem: (Movie movie) {
  Navigator.push(
    context,
    MaterialPageRoute(builder: (context) => MovieDetailPage(movie)),
  );
},

With that, our small screen UI is done! You should now be able to navigate to the detail screen and back:

See the changes

7. Convert movie list page into home page

As a first step to making our layout adaptive to different screen sizes:

Convert MovieListPage to a StatefulWidget. (In VS Code place the cursor on StatelessWidget, press CTRL/CMD + . and select "Convert to StatefulWidget".)
For semantic's sake rename it to HomePage and the file to home_page.dart.

On small screens the HomePage widget will contain only the MovieListView. On large screens the HomePage widget will contain the MovieListView and the MovieDetailView side by side. You'll understand why we converted the widget to a StatefulWidget in just a bit.

See the changes

8. Make the home page adaptive with the `adaptive_layout` package

To help us implement us display different layouts on different screen sizes we'll use the adaptive_layout package.

Install it with

$ flutter pub add adaptive_layout

This will add a line like this to your package's pubspec.yaml (and run an implicit dart pub get).

dependencies:
  adaptive_layout: ^0.1.3

Now in home_page.dart, import the package:

import 'package:adaptive_layout/adaptive_layout.dart';

Update the body of the Scaffold of HomePage to be an AdaptiveLayout with a smallLayout and a largeLayout like so:

class HomePage extends StatefulWidget {
  const HomePage({Key? key}) : super(key: key);

  @override
  _HomePageState createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  @override
  Widget build(BuildContext context) {
    final movies = Movie.getList();

    return Scaffold(
      appBar: AppBar(
        title: Text('Movies'),
      ),
      // Now using an `AdaptiveLayout` as the `body`
      body: AdaptiveLayout(
        // Provide `MovieListView` as the `smallLayout`
        smallLayout: MovieListView(
          movies: movies,
          onTapItem: (Movie movie) {
            Navigator.push(
              context,
              MaterialPageRoute(builder: (context) => MovieDetailPage(movie)),
            );
          },
        ),
        // Provide a `Row` as the `largeLayout`
        largeLayout: Row(
          children: [
            Expanded(
              child: MovieListView(
                movies: movies,
                onTapItem: (Movie movie) {
                  // TODO: Update detail view to the right
                },
              ),
            ),
            Expanded(
              child: Container(
                child: Center(
                  child: Text(
                    'Select a movie from the list on the left to see the details here.',
                  ),
                ),
              ),
            )
          ],
        ),
      ),
    );
  }
}

The smallLayout is just our MovieListView and the largeLayout is a 2-column Row with the MovieListView in the first Expanded column.

At this point, on small screens the app should have the same behavior as before of navigating to the detail page when a list item is tapped. On large screens we should now see the list on the left-hand side of the screen and the message "Select a movie from the list on the left to see the details here" in the center of the right-hand side of the screen:

However, nothing happens when we tap a list item on large screens. Let's tackle that next.

9. Display the detail view when an item is tapped on large screens

With a few new lines of code in the home_page.dart file we can display the detail view on the right hand side when an item is tapped on large screens.

Create a private property of the _HomePageState of type Movie? named _selectedMovie.

class _HomePageState extends State<HomePage> {
  Movie? _selectedMovie;

  ...

Update the onTapItem() callback of the MovieListView in the largeLayout of the AdaptiveLayout widget to update the _selectedMovie property with setState. This is why we converted the widget to a StatefulWidget a few steps ago.

// Within the `largeLayout`
onTapItem: (Movie movie) {
  setState(() {
    _selectedMovie = movie;
  });
},

Update the second Expandable of the Row to display the message if _selectedMovie is null and the MovieDetailView otherwise.

Expanded(
  child: Container(
    child: _selectedMovie == null
        ? Center(
            child: Text(
              'Select a movie from the list on the left to see the details here.',
            ),
          )
        : MovieDetailView(
            _selectedMovie!,
          ),
  ),
)

And... we're done! 🎉

On small, phone-sized, screens when the user taps an item they will navigate to a different screen with the details and on larger screens the details are displayed on the right side of the list and there is no navigation.

See the changes

BONUS: Make it look a little better on large screens

To make our app look a little better, let's leave the selected list item highlighted and put a divider line between the list view and the detail view with a few new lines of code in the home_page.dart file.

Add a new attribute selectedId attribute to MovieListView, so it knows which item a selected.

class MovieListView extends StatelessWidget {
  final List<Movie> movies;
  final Function(Movie) onTapItem;
  final int? selectedId;

  const MovieListView({
    Key? key,
    required this.movies,
    required this.onTapItem,
    this.selectedId,
  }) : super(key: key);

  ...

Update the itemBuilder of the ListView.builder to wrap the ListTile in a Container and give the Container color if the ListTile's movie is the selected one.

itemBuilder: (context, index) {
  final movie = movies[index];

  final color = movie.id == selectedId
      ? Theme.of(context).primaryColor.withOpacity(0.25)
      : Colors.transparent;

  return Container(
    color: color,
    child: ListTile(
      key: Key('list_item_$index'),
      leading: Image.network(SMALL_POSTER_BASE_URL + movie.posterPath),
      title: Text('${movie.title}'),
      contentPadding: EdgeInsets.all(12.0),
      onTap: () {
        onTapItem.call(movie);
      },
    ),
  );
},

Update the first Expandable of the Row in the largeLayout of the AdaptiveLayout to provide the selected movie's id to the MovieListView.

Expanded(
  child: MovieListView(
    movies: movies,
    onTapItem: (Movie movie) {
      setState(() {
        _selectedMovie = movie;
      });
    },
    selectedId: _selectedMovie?.id,
  ),
),

Lastly, let's add a border to the left-hand side of the detail view's Container with some BoxDecoration.

Expanded(
  child: Container(
    decoration: BoxDecoration(
      border: Border(
        left: BorderSide(
          color: Colors.grey[300]!,
          width: 1.0,
        ),
      ),
    ),
    child: _selectedMovie == null
        ? Center(
            child: Text(
              'Select a movie from the list on the left to see the details here.',
            ),
          )
        : MovieDetailView(
            _selectedMovie!,
          ),
  ),
)

Of course the sky's the limit with the design, but I think our app is minimally presentable now:

See the changes

BONUS: Tests

I chose not to TDD this so we could focus on the layout, but you can find the tests here in the source code.

Note in the tests that I use WidgetTester to specify a small screen size in a setUp function like this:

setUp(() {
  binding.window.physicalSizeTestValue = Size(
    AdaptiveLayout.getBreakpoints().mediumScreenMinWidth - 10,
    500,
  );

  binding.window.devicePixelRatioTestValue = 1.0;
});

and to specify a large screen size like this:

setUp(() {
  binding.window.physicalSizeTestValue = Size(
    AdaptiveLayout.getBreakpoints().largeScreenMinWidth + 10,
    500,
  );

  binding.window.devicePixelRatioTestValue = 1.0;
});

Head over the the Github repo to see the complete source code with a separate commit for each step 😉.

Congrats on making it to the end and thanks for following along! 👏 ❤️ ⭐ 🦄 🔖

Does TDD help you to write more SOLID code?

Touré Holder — Fri, 16 Apr 2021 09:50:29 +0000

It's clear to most that SOLID principles help us to produce more testable code and that unit testing promotes following SOLID principles.

I'm wondering if driving development through tests (TDD) helps you to follow SOLID principles any more that testing after development.

What do you think?

Does TDD slow you down or help you go faster?

Touré Holder — Fri, 16 Apr 2021 00:20:19 +0000

I have the impression that I spend less time doing manual testing and "thinking" about what to test when I do TDD. But I've heard very different opinions on this.

For those of you who've done a fair share of both test-driven development and test-last development, do you perceive any difference in the speed of getting your code to production?

Removing sensitive data from your Git history with BFG

Touré Holder — Wed, 07 Apr 2021 09:55:20 +0000

Here's how to remove sensitive data, like certificate files or passwords in your files, from your git repo and history with BFG Repo-Cleaner.

1. Remove the sensitive files and secrets from your code and commit changes

Note that, by default, BFG doesn't modify the contents of your latest commit. So, remove the sensitive files and secrets from your code, commit the changes and ensure that your latest commit is clean with none of the undesired data in it before proceeding.

2. Install BFG

You can download a JAR from the site. If you're on Mac, brew install bfg should suffice.

3. Clone a fresh copy of your repo, using the --mirror flag:

# Example
$ git clone --mirror git://example.com/my-repo.git

4. Clean sensitive files

Use --delete-files to nuke files in your repo history.

# Examples
$ bfg --delete-files certificate.p12 my-repo.git
$ bfg --delete-files keystore.jks my-repo.git
$ bfg --delete-files id_{dsa,rsa} my-repo.git
$ bfg --delete-files *.{txt,log} my-repo.git

Note that the specified name matches on file name, not on path within repo. So $ bfg --delete-files path/to/certificate.p12 my-repo.git won't work.

5. Clean sensitive strings

Use --replace-text to clean strings from your repo history. Each string will be rewritten as "***REMOVED***" by default. This is a two-step process.

5.1. Create a file with a new line for each string you want to remove

Create a simple text file however you'd like.

# Example
echo "password123" >> passwords.txt
echo "123password" >> passwords.txt

5.2. Run the command

Run bfg --replace-text referencing the file you just created.

# Example
$ bfg --replace-text passwords.txt my-repo.git

6. Take a look at your new history

Enter the folder of the git repo and make sure your history has been updated.

# Example
$ cd my-repo.git

# Use git commands to examine the history
$ git log
$ git show HEAD
$ git show HEAD~1
$ git show d89bb58

(You won't see the physical files of your working tree if you list files in this directory, since we did a bare/mirror clone, in case you were wondering.)

7. Strip out the unwanted dirty data

Once satisfied with the state of the history, clean up those sensitive files, which git now considers unnecessary.

$ git reflog expire --expire=now --all && git gc --prune=now --aggressive

8. Push

Finally, once you're happy with the updated state of your repo, push it back up and you're done!

$ git push

If you're with a team have everyone ditch their old copies of the repo and do fresh clones.

Thanks for following along. Cheers!

dyld: Symbol not found: _ffi_prep_closure_loc

Touré Holder — Mon, 03 Aug 2020 00:48:12 +0000

Did a regular flutter run targeting my iPhone simulator today and this craziness showed up on my screen.

Error output from CocoaPods:
↳
    dyld: lazy symbol binding failed: Symbol not found: _ffi_prep_closure_loc
      Referenced from: /Users/toure/.rbenv/versions/2.6.0/lib/ruby/gems/2.6.0/gems/ffi-1.13.1/lib/ffi_c.bundle
      Expected in: /usr/lib/libffi.dylib

    dyld: Symbol not found: _ffi_prep_closure_loc
      Referenced from: /Users/toure/.rbenv/versions/2.6.0/lib/ruby/gems/2.6.0/gems/ffi-1.13.1/lib/ffi_c.bundle
      Expected in: /usr/lib/libffi.dylib

After much longer than I liked, I found a fix buried in a github issue.

gem uninstall ffi
brew reinstall libffi
export LDFLAGS="-L/usr/local/opt/libffi/lib"
export PKG_CONFIG_PATH="/usr/local/opt/libffi/lib/pkgconfig"
gem install ffi

I decided to share this since the error in the title of the issue is different from the one that I got. Hope this can save someone some time.

The really effective part of TDD is not so much whether you write the test first (according to Uncle Bob)

Touré Holder — Sat, 25 Jul 2020 12:55:56 +0000

This post is also available in Portuguese 🇧🇷.

Do you know how this statement from Robert C. Martin ends?

"The really effective part of TDD is ..."

Robert C. Martin (colloquially known as Uncle Bob), is the author of the classic Clean Code book, one of the original authors of the Agile Manifesto and a real die hard defender of TDD as a tool to improve developer productivity and code quality.

Not too long ago I read an old blog post of his where he states that the really effective part of TDD is not so much whether you write the test first and I must admit I was somewhat taken aback.

This kinda shocked me because Uncle Bob is as pro-test-first-development as it gets. He's even said on occasion that writing tests after production code is a waste of time. 😱

So what could be so important, with regards to TDD, that Uncle Bob would consider it to be more important than the order in which we write tests and production code?

The answer lies in the history of the famous 3 Laws of TDD. You've probably seen them or some version of them:

You must write a failing test before you write any production code.
You must not write more of a test than is sufficient to fail, or fail to compile.
You must not write more production code than is sufficient to make the currently failing test pass.

In another of his blog posts called "The Cycles of TDD", Uncle Bob tells the story of how the 3 laws came to be as he recounts an experience he had while paring with Kent Beck, the father of Extreme programming (XP) and of TDD!

"I sat with Kent Beck in 1999 and paired with him in order to learn. What he taught me to do was certainly test first; but it involved a more fine-grained process than I’d ever seen before. He would write one line of a failing test, and then write the corresponding line of production code to make it pass. Sometimes it was slightly more than one line; but the scale he used was was very close to line by line."

...

"I, and many others, have written about these three laws over the years. They now appear in many different styles, formats, and injunctive statements. But the goal is always to promote the line by line granularity that I experienced while working with Kent so long ago."

This was a real AHA moment for me.

You see, I had always thought that I had to finish writing all the tests for whatever I was developing before touching the production code to actually be doing TDD.

I attribute this line of thought to the fact that I used to do Test-last Development, before trying out TDD. In other words, I used to code up the feature, doing exploratory testing all the while, and then write automated tests after the fact. So, in my head, TDD was just about inverting that order.

As a result, writing tests before the production code just sounded backwards to me. (And scared the living hell out of me.) I also see little sense in trying to complete a suite of tests without proper IntelliSense on a screen with all kinds of squiggly red lines in the IDE since the methods and properties being testing don't exist yet.

But as I drilled deeper into the study on the fundamentals of TDD, it became vividly clear how the practice is really grounded in repetitions of very small cycles of testing and implementation. In the book The Art of Agile Development (recommended by Martin Fowler), the author, James Shore, recommends working in cycles of testing and implementation no greater than 5 minutes or 5 lines of code.

If you're asking yourself what this looks like in action, I'd recommend watching these two videos: part of The Three Laws of TDD video and Tutorial: Mastering Test-Driven Development with Angular.

Since coming to all this realization I've been doing TDD almost exclusively and I've been finding the process very intuitive and fast. 😃

So let's wrap up, going back to the statement I asked you to complete at the beginning of this post and to the moment when Uncle Bob claimed that the really effective part of TDD is not so much whether you write the test first. 👀

I found it in yet another of his posts where he talks about a study that basically concludes that TDD doesn't produce higher quality code than other methods of development.

You should definitely read the whole thing some time to understand the context of the statement, but I'll sum it up for you: In the study, 58 developers where divided into 2 groups and asked to do a programming task. One group had to do TDD while the other did TLD (Test-last development). Both groups were asked to work on small chunks of the task, rather than utilize a waterfall approach. At the end of the experiment, metrics where compared and the study concludes that "TDD does not affect testing effort, software external quality, and developers’ productivity."

What do you have to say about that Uncle Bob?

In his analysis, Uncle Bob points out that the study asked the folks doing TLD to work in “small chunks”, inadvertently forcing both groups to use the TDD process of short cycles, and writes:

"The really effective part of TDD is the size of the cycle, not so much whether you write the test first. The reason we write the tests first is that it encourages us to keep the cycles really short."

And there you have it. Thanks for the read!

A efetividade real de TDD não está no fato de escrever o teste antes do código (segundo Tio Bob)

Touré Holder — Wed, 22 Jul 2020 11:27:35 +0000

This post is also available in English.

Tente imaginar como esta frase do Robert C. Martin termina:

"The really effective part of TDD is ..."

Robert C. Martin, (carinhosamente conhecido como Tio Bob) é autor do livro clássico Código Limpo, um dos autores originais do Manifesto Agile e um defensor ferrenho da prática de TDD como uma ferramenta para aumentar a produtividade de desenvolvedores e a qualidade do código produzido por eles.

Recentemente li um post (antigo) no blog do Tio Bob no qual ele afirma que a efetividade real de TDD não está no fato de escrever o teste antes do código de produção e confesso que fiquei um tanto quanto ... chocado.

Esta afirmação me chamou muito atenção porque o evangelismo do Tio Bob a favor de TDD é implacável. Tão implacável que ele já foi capaz de afirmar que escrever testes depois de escrever código de produção é um desperdício de tempo. 😱

Então, qual fator poderia ser tão importante para a prática de TDD ao ponto do Tio Bob considerá-lo mais importante que a relação de ordem entre a criação de testes e a criação do código de produção?

A resposta repousa na história das famosas 3 Leis de TDD. Você provavelmente já ouviu essas 3 leis ou pelo menos alguma versão delas:

Não é permitido escrever código de produção a não ser que seja para fazer passar um teste que esteja falhando.
Não é permitido escrever mais do teste do que seja necessário para fazer o teste falhar, ou deixar de compilar.
Não é permitido escrever mais código de produção do que o suficiente para fazer um teste passar.

Em outro post no seu blog, intitulado "Os Ciclos de TDD", o Tio Bob conta como as 3 leis se originaram enquanto relata uma experiência que teve quando pareou com Kent Beck, o criador da metodologia Extreme programming (XP) e da prática de TDD!

"Eu me sentei para parear com Kent Beck em 1999 para aprender. De fato ele me ensinou a escrever os testes primeiro, mas em um processo mais granular do que eu já tinha visto antes. Ele escreveria uma linha de teste que falharia e então escreveria uma linha de código de produção correspondente para fazer o teste passar. Às vezes era um pouco mais de uma linha, mas a escala que ele utilizava era muito próximo de linha a linha.

....

O objetivo de escrever sobre as 3 leis sempre foi promover essa granularidade linha a linha que eu experimentei enquanto trabalhava com Kent.” (Tradução livre)

Não sei se a frase acima teve o mesmo impacto revelador em você que teve em mim quando a li pela primeira vez. But, I was mind blown.

Quando comecei a tentar fazer TDD, eu achava que só estaria fazendo TDD de verdade se eu terminasse de escrever todos os testes da funcionalidade que eu iria implementar, antes de encostar no código de produção.

Eu atribuo esta linha de pensamento ao fato de eu praticar apenas Test-last Development (TLD), antes de me aventurar no mundo de TDD. Ou seja, eu implementava uma funcionalidade e depois de estar satisfeito com os resultados de testes exploratórios, eu então escrevia testes automatizados. Na minha cabeça TDD seria apenas uma inversão desta ordem.

Resultado: A ideia de escrever testes antes de escrever código de produção me parecia pouco intuitivo (e me apavorava). Também não via (e continuo não vendo) praticidade em tentar completar um conjunto de testes sem IntelliSense e com quase todas as linhas sublinhadas de vermelho pelo IDE pelo fato dos métodos e propriedades da classe a ser implementada não existirem ainda.

Ao me aprofundar no estudo sobre o tema, encontrei várias fontes que frisam o fato de que a prática de TDD é fundamentada em repetições de pequenos ciclos de teste e desenvolvimento. Por exemplo, no livro The Art of Agile Development, (leitura indicada pelo Martin Fowler), o James Shore recomenda trabalhar em ciclos de teste e desenvolvimento que não passam de 5 minutos ou de 5 linhas de código.

Se você estiver se perguntando como isso funciona na prática, recomendo 2 vídeos:
Tutorial: Mastering Test-Driven Development with Angular e
este trecho do vídeo The Three Laws of TDD

Com esta realização, eu voltei a praticar TDD, seguindo as 3 leis à risca na maior parte do tempo e hoje o processo tem se tornado muito mais intuitivo e rápido. 😃

Para finalizar, vamos voltar àquela frase incompleta do início deste post e o momento em que o Tio Bob é pego com a boca na botija, flagrado, afirmando que a efetividade real de TDD não está no fato de escrever o teste antes do código de produção. 👀

Eu encontrei a afirmação em outro post do seu blog no qual o ele analisa um estudo que conclui que a prática de TDD não tem um impacto significativo sobre a qualidade do software produzido por equipes.

Aconselho fortemente ler o post na sua integridade para entender o contexto da afirmação, mas para resumir o estudo: 58 desenvolvedores foram divididos em 2 grupos para realizar alguns desafios de programação. Um grupo deveria fazer TDD enquanto o outro grupo fizesse TLD (Test-last development). Os 2 grupos foram orientados a trabalhar em pequenos ciclos de desenvolvimento e testes e não de uma forma cascata. No final, métricas foram comparadas e o estudo conclui que TDD não tem efeito (nem positivo, nem negativo) sobre a produtividade dos desenvolvedores nem sobre a qualidade do código produzido.

Então, porque raios a gente deveria escrever testes antes do código de produção?

Em resposta a este estudo, o Tio Bob destaca o fato que tanto os devs do grupo de TDD quanto os do grupo de TLD trabalharam em pequenos ciclos e afirma:

"A efetividade real de TDD está no tamanho do ciclo, e não no fato de escrever o teste antes. Escrevemos testes antes porque isso nos motiva a manter os ciclos muito pequenos." (Tradução livre)

Texto original:
"The really effective part of TDD is the size of the cycle, not so much whether you write the test first. The reason we write the tests first is that it encourages us to keep the cycles really short."

Wow!

Obrigado por ler até o final (ou por pular para o final só para ver a resposta). Espero que o post tenha sido enriquecedor para você!

Easy Continuous Delivery with Travis CI and Firebase hosting

Touré Holder — Sun, 05 Jul 2020 13:56:29 +0000

Continuous delivery with Travis CI and Firebase hosting. It's as easy as 1, 2, 3.

1. Select the repository you want to use with Travis CI.

Click on your profile picture in the top right of your Travis Dashboard, click Settings, and toggle the repositories you want to use with Travis CI. See the docs.

2. Add your Firebase CI token to your environment variables

On your command line install Firebase CLI, initiate your project and generate a CI token, like so:

# Install the CLI
npm install -g firebase-tools

# Run this command from your app’s root directory
firebase init

# This will print out a new access token 
firebase login:ci

Then go to your repository settings in Travis CI: Dashboard > menu icon of the repository > Settings.

In the Settings page, add a new environment variable called FIREBASE_TOKEN with the access token you just generated on the command-line as the value and be sure to leave "Display value in build log" turned off since your token should be stored securely.

3. Add a `.travis.yml` file to your repository

Create a .travis.yml file with these two commands in an appropriate phase.

  - npm install -g firebase-tools
  - firebase deploy --token "$FIREBASE_TOKEN"

Here's a complete example of a simple an Angular CI/CD pipeline.

dist: trusty
sudo: false

language: node_js
node_js:
  - "10"

addons:
  chrome: stable

cache:
  directories:
     - ./node_modules

install:
  - npm install

script:
  - npm build
  - npm run test -- --no-watch --no-progress --browsers=ChromeHeadless


after_success:
  - npm install -g firebase-tools
  - firebase deploy --token "$FIREBASE_TOKEN"

Push a commit with your .travis.yml and the files generated by firebase init to your remote and that should be enough to kick-off your build and deploy your app to Firebase.

Context

I want to finish up explaining why I wrote yet another Travis CI + Firebase hosting post.

While setting up continuous delivery of my Angular app I had a very hard time using the Travis CI Firebase Deployment provider.

Firstly, I couldn't get the Travis CLI to work on my Mac due to annoying Xcode and command-line tools related errors like this one:

dyld: lazy symbol binding failed: Symbol not found: _ffi_prep_closure_loc
  Referenced from: /Users/toure/.rbenv/versions/2.6.0/lib/ruby/gems/2.6.0/gems/ffi-1.13.1/lib/ffi_c.bundle
  Expected in: /usr/lib/libffi.dylib

After googling 'dyld: lazy symbol binding failed: Symbol not found: _ffi_prep_closure_loc' and going through issues and Stack overflow answers about updating my Xcode tooling and whatnot, to no avail, I gave up on trying to add an encrypted firebase token to my .travis.yml.

I then added the token to my environment variables and tried to keep using the Travis CI Firebase provider, but even though I could print and see the token in the pipeline, I couldn't get authentication to work. Maybe I wasn't escaping the special characters right or something.

Error: HTTP Error: 401, Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential.

So, I ended up giving up altogether on the Firebase provider and doing it the way I described in this post. Which is actually the same way I do it with other CI/CD tools that I use, like Bitbucket pipelines.

Thanks for reading! Let me know what you think of the post :)

Forem: Touré Holder

Should one get good at test-last development before learning TDD?

Creating adaptive layouts with Flutter

Small screen UI

Large screen UI

Live demo

Let's go!

1. Create a new app

2. Provide the data set

3. Create the model

4. Create the movie list page

5. Create the movie detail page

6. Navigate to the detail screen when an item is tapped

7. Convert movie list page into home page

8. Make the home page adaptive with the adaptive_layout package

9. Display the detail view when an item is tapped on large screens

BONUS: Make it look a little better on large screens

BONUS: Tests

Does TDD help you to write more SOLID code?

Does TDD slow you down or help you go faster?

Removing sensitive data from your Git history with BFG

1. Remove the sensitive files and secrets from your code and commit changes

2. Install BFG

3. Clone a fresh copy of your repo, using the --mirror flag:

4. Clean sensitive files

5. Clean sensitive strings

5.1. Create a file with a new line for each string you want to remove

5.2. Run the command

6. Take a look at your new history

7. Strip out the unwanted dirty data

8. Push

dyld: Symbol not found: _ffi_prep_closure_loc

The really effective part of TDD is not so much whether you write the test first (according to Uncle Bob)

A efetividade real de TDD não está no fato de escrever o teste antes do código (segundo Tio Bob)

Easy Continuous Delivery with Travis CI and Firebase hosting

1. Select the repository you want to use with Travis CI.

2. Add your Firebase CI token to your environment variables

3. Add a .travis.yml file to your repository

Context

8. Make the home page adaptive with the `adaptive_layout` package

3. Add a `.travis.yml` file to your repository