This is an automated email from the ASF dual-hosted git repository.
skygo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans-website.git
The following commit(s) were added to refs/heads/master by this push:
new 75e2dce40 add quality evangelism page
new c2c3e6eda Merge pull request #605 from ebarboni/qualityevangelism
75e2dce40 is described below
commit 75e2dce40172f8bd0b132abc0df7fff7121dce1c
Author: Eric Barboni <sk...@apache.org>
AuthorDate: Tue Aug 9 14:45:56 2022 +0200
add quality evangelism page
---
.../content/participate/qualityevangelism.asciidoc | 125 +++++++++++++++++++++
1 file changed, 125 insertions(+)
diff --git
a/netbeans.apache.org/src/content/participate/qualityevangelism.asciidoc
b/netbeans.apache.org/src/content/participate/qualityevangelism.asciidoc
new file mode 100644
index 000000000..fa7d7d8e8
--- /dev/null
+++ b/netbeans.apache.org/src/content/participate/qualityevangelism.asciidoc
@@ -0,0 +1,125 @@
+////
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+////
+= Quality Evangelism
+:jbake-type: page
+:jbake-tags: community, needsreview
+:jbake-status: published
+:keywords: quality evangelism in Apache NetBeans
+:description: quality evangelism to Apache NetBeans
+:toc: left
+:toclevels: 4
+:toc-title:
+
+*Motivation:* Increase the quality and reliability of our codebase - the
Apache NetBeans modules.
+
+When developing - writing new code, refactoring or just bug fixing - people
always make mistakes and produce new bugs.
+This is an unavoidable fact and there is almost nothing we can do to prevent
ourselves from making mistakes when coding (perhaps writing less code).
+That's why we should carefully learn how to find our own mistakes reliably and
quickly.
+The sooner the bug is found and fixed the better, because once the bug is
fixed can no longer negatively influence further work.
+The best solution would be to find and fix all bugs before the code containing
them is committed into the version control system and the bugs can disrupt
others who use the code.
+
+Every developer is excited when designing and writing new features and every
developer hates fixing and code maintenance.
+In reality developers spend significantly more time on bug fixing than
developing new features, don't you think? Why?
+They haven't found their own mistakes before putting the code into the user's
hands!
+Finding bugs immediately after writing new code will give you more time for
new features and for fun.
+Besides that, it will make your users happy and your boss satisfied. Yes, so
much good can come just from having no bugs.
+
+== How to find bugs? ==
+
+In Apache NetBeans there are several instruments which we use to find bugs.
+They are focused on different levels of testing, use different methodology and
have different complexity, but in the end they all test the code and are
capable of detecting bugs.
+Hopefully the list isn't final and will soon grow.
+
+////
+=== Milestones Process ===
+
+The NetBeans QE team releases Milestones to assure a basic level of quality
during the release cycle.
+The Milestone Process is well-established among the developer community.
+Milestones reports are published on the NetBeans site and announced on the
nb...@netbeans.org mailing list.
+There are strict rules followed by all developers about when and how to fix
Milestone stopper bugs.
+////
+=== Commit Validation Suite ===
+
+The Commit Validation Suite should help all developers to verify that the
changes they are going to push to the Apache NetBeans git repository don't
break any vital functionality provided by the Apache NetBeans modules.
+This is the suite of tests gathered among Apache NetBeans modules which
developers should run before pushing their changes to the git repository.
+Remember, your bugs may disturb other developers around the globe.
+
+The Commit Validation Suite can be extended by any module whose functionality
the developers consider vital and should be tested before every commit.
+You can read more about link:submit-pr.html[commit guidelines].
+
+=== Unit tests ===
+
+The Apache NetBeans developers and former QA team invested a lot of time in
implementing an easy-to-use framework allowing to write and run unit tests.
+Nowadays I doubt there are any developers who have never heard of unit testing
or think that writing unit tests is a bad thing.
+Unfortunately, the reality is that even those developers still do NOT write
any tests.
+Why? They haven't discovered the benefits.
+
+==== Why write unit tests? ====
+
+
+* *Tests represent the most practical design spec possible* - Unit tests
constitute design documentation that evolves naturally with a system.
+This is the Holy Grail of software development, documentation that evolves
naturally with a system.
+What better way to document a class than to provide a coded set of use cases.
+That's what these unit tests are: a set of coded use cases that document what
a class does, given a controlled set of inputs.
+As such, this design document is always up-to-date because the unit tests
always have to pass.
+
+* *Tests give a developer confidence in the code* - you can always check
whether your change breaks something or not by running tests.
+Well-written tests should catch all potential regressions.
+
+* *Tests are the lab* - when testing your code this is usually done in
laboratory environment which eliminates dependencies and side-effects caused by
other parts of code.
+You can test each functionality separately which will allows you to quickly
track the problem.
+You can't expect your code to work in the production environment if it doesn't
in the lab.
+
+* *Tests speed up refactoring* - by coding a set of use cases into your tests
you can easily verify that you are not compromising any functionality or
causing incompatibilities when refactoring your code.
+Well written tests should catch all potential incompatibilities.
+
+* *Tests help to fight memory leaks* - it's usually hard to find memory leaks
in a program, and it's harder when the program is big and complex.
+Running tools like OptimizeIt doesn't necessarily help in all cases and it's
usually slow.
+It's better to write tests for isolated pieces of code (subsystems) which
check whether your objects are really getting garbage collected when they
aren't used anymore.
+
+* *Tests will make your boss more happy* - by writing tests your code will be
more stable attracting more users, making the product more successful.
+That's what all bosses like!
+
+
+==== How many tests do I need to write? ====
+
+All of them, and it still will not be enough! Seriously, you should write as
many tests as possible, ideally the tests should cover all the code in your
module.
+Practically this is hard to achieve and software projects usually define some
lower level of code coverage as sufficient.
+However, the code coverage by unit tests should be at least 70% for production
quality code.
+This is a high number!
+
+The problem with code coverage by tests is that even 100% coverage doesn't
mean that there are no bugs in the tested code.
+This is because your code behaves according to the state of memory and thus
you shouldn't only exercise each line of your code but exercise it for each
possible state of memory.
+Obviously threading issues bring even more complexity to the problem.
+
+==== When to write Unit tests? ====
+
+In Apache NetBeans, currently we have a lot of code which isn't covered by
tests.
+Trying to write tests for all this code sounds like a never-ending task and in
fact it's not really practical to stop all work and write tests for all the
code now!
+Instead we should establish few rules about how to continuously improve the
situation and increase the number of code lines covered by tests.
+And here it goes:
+
+* All newly written code should be covered by unit tests
+
+* When fixing a bug, a test should be written to simulate the bug and then
verify that the fix really solved the problem.
+
+* Whenever you feel tired by your current work try to write some tests for
existing code which isn't tested enough yet (there is a lot of untested code
overall in the Apache NetBeans sources).
+
+
+
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
