No-Run Development - You DON'T need to run your project to develop it

No-Run Development - You DON'T need to run your project to develop it

Hello, Web Developers!

Over the past 10 years, I've been continuously refining my programming skills and organizing my projects. I love exploring new things, tools, hacks, automation, and shortcuts to enhance my performance.

And I have to say: YOU DON'T NEED TO RUN YOUR PROJECT TO DEVELOP IT! And you'll thank me later ??

I call this set of practices No-Run Development.


Why don't you need to run your project? What are the advantages?

Well, in a simple and concise way, development can be faster, safer, more reliable, and requires less computer power. The secret lies in using (or not using) specific tools that you are likely already familiar with!

Let's dive into back-end and front-end!


Back-End:

How do you develop your back-end? Here are some ways I see many people doing it:

  1. Running queries on the database to verify behavior and then incorporating it into the code.
  2. Creating an entire flow (e.g., controller, service, repository) and testing the output with tools like Postman, Insomnia REST, Thunder Client, etc.
  3. Creating files that access REST APIs to check the response.

Option 1 takes some time, as after the query, you still need to bring it into your code. Wouldn't it be better to do everything directly in the code?

Option 2 is good; it allows API documentation, but it also takes time. Not to mention that it requires authentication, and many programmers may not fully leverage the power of these tools.

Option 3 is terrible. Never do that ??????

How I do Back-End:

I start with functions that access the database. How do I know if I'm writing the commands correctly? Simple! Write tests!

At the beginning of each test, I register the data, and at the end of each test, I clean the database to ensure the next test won't be influenced by the mess of the previous one.

You can use a real database or an in-memory database.

  • A real database will show the exact behavior of how it will behave with your application, but it's slower.
  • An in-memory database is much faster. But since it's not your real database, in some cases, it may behave slightly differently.

Want to try a query, insert data, or update something? In these tests that constantly clean the database, it's quick and straightforward. Every time you save your file, it will execute, and you'll immediately see the result. You can print the result to the console during creation to see what's being created, without the need to add breakpoints. It's like being in a sandbox. Feel free to make a mess without consequences!

Tip: You can restrict your testing tool to run only the file you're working on so that the tests run faster.


Once you finish the functions that access the database, you can turn off the database! We won't need it anymore because you've already tested all your functions!


Next, we can create other parts like services and controllers. If there's database access, we can mock these functions to return fixed values. No need to worry; we've already tested everything, remember?

Mocking the database return will make our tests even faster and won't make us dependent on the running database. Here, I usually configure my testing framework to ignore the database access files that we've already tested, as there's no need to test a layer already tested.

Here we have the same idea as before: since our project isn't running, the only way to know if we're getting the expected result is to write tests! Every time we save a file, our code is executed, and we can see the result in the console.

If you need to test various things, having all of this in the code is much faster than configuring and accessing APIs through tools like Insomnia or Postman.

And the best part: since the only way to work was with tests, our system is already tested!

Need to change something? The tests will show you where it's breaking and what you need to fix! In other words, No-Run Development is a kind of TDD, where you have no choice but to write tests to know what you're doing.


Front-End:

Just because the front-end is visual doesn't mean you have to run your entire project and open the browser!

These days, it's common to focus on creating components. An excellent tool for this is Storybook. It's a tool that lists the components we're creating.


We can test our components and control them as we want. This is useful because if we had to start our project, the component would be on some page. To test it, you might have to fill out a form and click on various buttons to get to the screen where your component is.


Another advantage of Storybook is that your component is being tested in an isolated environment. That means no other elements of the system can influence your component, whether JavaScript or CSS!

Moreover, the result of Storybook is a list of components and their properties, which ends up serving as documentation. And we still haven't run our project!


Other parts of the front-end can follow the same ideas as the back-end: create functions and run tests to know what they're returning.

Need to test a function that accesses an API? Make a mock and return a fixed value! No need to worry; we've already tested the back-end functions, remember?


If you have things like React Hooks, I always recommend leaving the logic in a JavaScript function and calling that function inside the Hook. Because this way, it's simpler to test the logic, and you can reuse these functions anywhere, even outside of React.


See! We've practically dealt with an entire system, and we still haven't had to start our project, in addition to having excellent test coverage!


To create the screens, then, we will need to start our server. And you can still create tests with tools like Cypress or Playwright.


Don't create files!

Don't spend time creating files and configuring tests!

One of the tools I use the most is Plop.js! With it, I can define templates to generate files with the structure and name I want.


In other words, to create something new, I just run one command and have more than 10 files generated in a specific pattern, with ready-made code and tests. I just need to fill it with my logic and business rule.

This is great, especially when a new person joins the team. They don't need to know 100% of the structure and which files to create. Just run the command and write what you need.

Plop.js is used by major companies today, such as Microsoft, Mozilla, Adobe, MasterCard, PayPal, etc.


So, what are the advantages of No-Run Development?

Well, once I worked on a very heavy project with 6 Docker containers and full of bugs and memory leaks. My PC, even with 32GB of DDR4 memory, Core i9 9900KS, and RTX-2080TI, struggled to run it.

The only way to program without having successfully run the project was to run tests on specific files I was working on or use Storybook, isolating my work.


The result is working in a way where tests are the only way to know what you're doing, resulting in a well-tested system following the TDD idea. Moreover, your computer won't need to spend resources on the entire system because you only need to run tests for a specific group of files.

Even if the system is large and slow, everything will be very fast because you'll only be running a few tests.

You only need to run the project at the end to bring everything together and ensure everything is working.

But for most of the time, you don't need to run your project. Not even the database!

This is No-Run Development!

Share this post with your colleagues and friends! I know your productivity and system quality will improve!!!

要查看或添加评论,请登录

Akira Hanashiro的更多文章

社区洞察

其他会员也浏览了