Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

blog: drafts smart testing article. #424

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

hemanik
Copy link
Member

@hemanik hemanik commented Feb 12, 2018

Short description of what this resolves:

Drafts an article showcasing different use-cases for Smart Testing.

Fixes: arquillian-organization/issues/20

@hemanik hemanik changed the title blog: Drafts smart testing article. blog: drafts smart testing article. Feb 12, 2018
Copy link
Contributor

@MatousJobanek MatousJobanek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot @hemanik
Please, change the name of the file with the latest date - to make it visible on the main page.


h1. Smart Testing For Fast Feedback

p<>. ??As an engineer, you should constantly work to make your feedback loops shorter in time and/or wider in scope.??
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for quotations block use bq.
the question marks are not necessary there, I believe. same for the line 12


This vicious cycle of programming and testing doesn’t just slow you down in terms of time spent (especially with long-running tests), the involved "context switching":https://www.petrikainulainen.net/software-development/processes/the-cost-of-context-switching/ also drains your mental energy, which might ultimately destroy your productivity.

Here, fast feedback means that the time between changing code (or tests) and getting results from running the tests is reduced to a minimum. In other words, you end up with a fast edit-compile-test loop. The great thing about this, as "Joel Spolsky put it":http://www.joelonsoftware.com/articles/fog0000000023.html: “the faster the Edit-Compile-Test loop, the more productive you will be”.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would change the word here with something else, eg: From our point of view


Here, fast feedback means that the time between changing code (or tests) and getting results from running the tests is reduced to a minimum. In other words, you end up with a fast edit-compile-test loop. The great thing about this, as "Joel Spolsky put it":http://www.joelonsoftware.com/articles/fog0000000023.html: “the faster the Edit-Compile-Test loop, the more productive you will be”.

For almost every new feature added to the application, there is also a test written. This way, whenever someone changes the user interface, the system will be able to catch the differences and signal the team about any issues. They're still not integrated into the main pipeline. The plan is to merge them in to gain more confidence in what they build. The tests should run whenever anyone pushes changes to the git repository.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what is meant by this paragraph. It doesn't seem to fit here.


One of the biggest issues that plague the software development life cycle is the slow feedback loop, the time between changing code (or tests) and getting results from the tests.

h2. Impact of Slow Feedback Loop
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole section is very long. I would split it into smaller parts - subsections for example: "delays", "context switching", "resources"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, the name of this section could be just: "Motivation"

tags: [ testing, guide, smart-testing ]
---

h1. Smart Testing For Fast Feedback
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't that be Smart Testing For Fast Feedback Loop or maybe just Smart Testing?


For almost every new feature added to the application, there is also a test written. This way, whenever someone changes the user interface, the system will be able to catch the differences and signal the team about any issues. They're still not integrated into the main pipeline. The plan is to merge them in to gain more confidence in what they build. The tests should run whenever anyone pushes changes to the git repository.

Work starts on the new CD pipeline and everything is set up accordingly. The pipeline structure looks like below:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm missing the purpose of the next lines - it should be a description of the developer's workflow? I'm not sure if it is really necessary to describe the whole process here, just highlight the most important things...


h2. How does Smart Testing shorten the Feedback Loop?

There are a couple things you can do to shorten the feedback loop. You should absolutely invest in your tests and make them faster. Besides trying to implement faster tests, however, you can also optimize the way you run them.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would keep only the first sentence:
There are a couple things you can do to shorten the feedback loop. then name the possibilities:

  • don't run the tests
  • make test faster
  • parallelization
  • buy more resources
  • prioritize
  • minimize test suite

then describe the problems of the approaches - not running the tests is not a good idea; making test faster is hard (as you wrote there); parallelization is great, but you can do it to some limit; buying more resources - the limit is the budget. So we have prioritization and minimization of the test suite, but how to do it? Which tests should we choose? and then you can jump to the options/strategies etc...

"Smart Testing":http://arquillian.org/smart-testing/ aids you in optimizing the way you run tests.

During development, don’t run the entire test suite each time you change a bit of code. Aside from the fact that running all tests is often too slow, it’s always better (and faster!) to first get feedback on local code changes before integrating with other code. Reducing the scope and testing a small subset of code in isolation is not only faster, it also helps you find bugs, and it’s a must-have for TDD. (It goes without saying that at some point you or your continuous integration system should run all the tests.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside from the fact that running all tests is often too slow, it’s always better (and faster!) to first get feedback on local code changes before integrating with other code. Reducing the scope and testing a small subset of code in isolation is not only faster, it also helps you find bugs, and it’s a must-have for TDD. (It goes without saying that at some point you or your continuous integration system should run all the tests.)
This is not about Smart Testing and its functionalities at all

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants