Unit Testing - Revision history

Aponomarenko: /* Improved Patch/Cherry-pick Process */ Move links to a separate page with the short description of how to use it.

2015-10-26T10:35:36Z

Improved Patch/Cherry-pick Process: Move links to a separate page with the short description of how to use it.

Mbland: /* Tech Writer */ Add Lisa Carey to the Tech Writer team! :-)

2014-06-26T18:32:10Z

Tech Writer: Add Lisa Carey to the Tech Writer team! :-)

Ckomlo: /* Tutor */

2014-06-20T16:57:31Z

Tutor

Mbland: /* Howtos and Style Guides */

2014-06-10T16:24:39Z

Howtos and Style Guides

Mbland: Link to new Testing and Development Tools and Tips page

2014-06-10T16:23:51Z

Link to new Testing and Development Tools and Tips page

Franc: /* How to Manage Private Symbols */

2014-06-07T17:49:05Z

How to Manage Private Symbols

Jwalton: Moved Goals section to top of list after introduction.

2014-06-07T02:39:12Z

Moved Goals section to top of list after introduction.

Jwalton: Wikified Team section.

2014-06-06T19:35:20Z

Wikified Team section.

Mbland at 17:52, 6 June 2014

2014-06-06T17:52:05Z

Mbland at 17:39, 6 June 2014

2014-06-06T17:39:53Z

@@ Line 152: / Line 152: @@
 === Improved Patch/Cherry-pick Process ===
-Geoff Thorpe: (a) patches that are not applied/cherry-picked to all the branches they apply to, or (b) applied to more branches than they should be. A complication of (a) is that some patches may need to be reworked in order to apply (or in order to not break binary compatibility of a stable branch). The difficulty of (b) is determining when the nature of the change either breaks binary compatibility or causes some other behavioral deviation that is not in keeping with the "promises" of stable branches.
+Geoff Thorpe: (a) patches that are not applied/cherry-picked to all the branches they apply to, or (b) applied to more branches than they should be. A complication of (a) is that some patches may need to be reworked in order to apply (or in order to not break binary compatibility of a stable branch). The difficulty of (b) is determining when the nature of the change either breaks [[Binary_Compatibility|binary compatibility]] or causes some other behavioral deviation that is not in keeping with the "promises" of stable branches.
 Geoff on 2014-05-30: ...we might move to a scheme whereby we only maintain one most-recent stable branch for production releases, with snapshots or whatever of the development head. Ie. two branches, one for maximum-compatibility/bug-fixes-only, and the other for more active development. The number of "stable" branches would thus be 1 rather than 'n'. The idea is that we may defer to downstream "slow-moving" users (eg. long-term releases of linux distros) the opportunity to step up and do the work of maintaining (cherry-picking, back-porting, ...) older branches. Ie. what they typically already do in-house, but the opportunity to do it under our roof and thus combine their efforts with any other similarly-interested parties. If there's noone prepared to do that, the logical conclusion is that there is probably no need for it (or so the argument goes).

@@ Line 31: / Line 31: @@
 === Tech Writer ===
-Contacts: [mailto:mbland@acm.org Mike Bland], Sandeep Mankar, Chelsea Komlo, Graham Brooks
+Contacts: [mailto:mbland@acm.org Mike Bland], Sandeep Mankar, Chelsea Komlo, Graham Brooks, Lisa Carey
 Maintains documentation of tools, techniques, outstanding issues, etc. May maintain a code review/testing style guide based on the community consensus. Also documents who currently fills each role, as well as who might've filled it in the past.

@@ Line 49: / Line 49: @@
 === Tutor ===
-Contacts: [mailto:mbland@acm.org Mike Bland], Darshan Mody, Tom Francis, Brian N. Makin, Chelsea Komlo, Edward Knapp, Dileep Bapat, Graham Brooks
+Contacts: [mailto:mbland@acm.org Mike Bland], Darshan Mody, Tom Francis, Brian N. Makin, Edward Knapp, Dileep Bapat, Graham Brooks
 Helps contributors, particularly new contributors, with the details of writing unit or other automated tests. May be assigned by the reviewer of a patch to help a contributor get a new change under test. Submission of the patch should require the approval of the tutor in most cases. (Should ideally be more than one person.)

@@ Line 63: / Line 63: @@
 * [[How To Write Unit Tests For OpenSSL]]
 * [http://mike-bland.com/2014/06/05/pseudo-xunit-pattern.html The Pseudo-xUnit Pattern]
-* [[Testing And Development Tools and Tips]]
+* [[Testing and Development Tools and Tips]]
 == Discussion Topics ==

@@ Line 63: / Line 63: @@
 * [[How To Write Unit Tests For OpenSSL]]
 * [http://mike-bland.com/2014/06/05/pseudo-xunit-pattern.html The Pseudo-xUnit Pattern]
 == Discussion Topics ==

@@ Line 140: / Line 140: @@
 Not trying to be argumentative, I just want to understand the
 rationale. I'll work with whatever environment I have to.
 === Improved Patch/Cherry-pick Process ===

@@ Line 1: / Line 1: @@
 This page will track the effort to improve unit test and other automated test coverage for OpenSSL. Everyone is encouraged to help with this effort, but this page will track which community members have accepted specific responsibilities, and what tasks are currently underway.
 == Discussion List ==
@@ Line 39: / Line 52: @@
 Helps contributors, particularly new contributors, with the details of writing unit or other automated tests. May be assigned by the reviewer of a patch to help a contributor get a new change under test. Submission of the patch should require the approval of the tutor in most cases. (Should ideally be more than one person.)
 == Tasks ==

@@ Line 5: / Line 5: @@
 == Team ==
 We can define new roles as needed. The success of this effort will be inversely proportional to the number of roles with any one individual's name next to them. Each role can have more than one person filling it, but needs specific people to fill them.
 The point is not to tell people what to do and not do: it’s to establish clear responsibilities so everyone can run with them right away and begin applying their creative energy to solutions, rather than waste it figuring out what the hell is going on, what they should do to contribute, and who they need to coordinate with to get things done.
-'''Organizer''': [mailto:mbland@acm.org Mike Bland]<br />
+=== Organizer===
 Ensures the overall effort is making progress by facilitating communication, removing obstacles, and making hands-on contributions when necessary.
-'''Tech Writer''': [mailto:mbland@acm.org Mike Bland], Sandeep Mankar, Chelsea Komlo, Graham Brooks<br />
+=== Tech Writer ===
 Maintains documentation of tools, techniques, outstanding issues, etc. May maintain a code review/testing style guide based on the community consensus. Also documents who currently fills each role, as well as who might've filled it in the past.
-'''Buildmaster''': [mailto:mbland@acm.org Mike Bland], Isaac Truett, Dileep Bapat, Graham Brooks<br />
+=== Buildmaster ===
 Sets up and maintains automated builds and any infrastructure used to monitor them and report breakage.
-'''Toolsmith''': Tony Aiuto
+=== Toolsmith ===
 Maintains any tools and frameworks that are a part of the core build process; proposes, integrates, and/or retires existing tools.
-'''Tutor''': [mailto:mbland@acm.org Mike Bland], Darshan Mody, Tom Francis, Brian N. Makin, Chelsea Komlo, Edward Knapp, Dileep Bapat, Graham Brooks<br />
+=== Tutor ===
 Helps contributors, particularly new contributors, with the details of writing unit or other automated tests. May be assigned by the reviewer of a patch to help a contributor get a new change under test. Submission of the patch should require the approval of the tutor in most cases. (Should ideally be more than one person.)

@@ Line 2: / Line 2: @@
 == Discussion List ==
-[https://groups.google.com/forum/#!forum/openssl-testing openssl-testing] is the mailing list dedicated to the unit/automated testing effort, to avoid clogging openssl-dev. Membership is open to whoever wishes to join, even if only to lurk. Ideally all testing discussions will eventually move to openssl-dev once we have processes, tools, conventions, etc. in place.
+[https://groups.google.com/d/forum/openssl-testing openssl-testing] is the mailing list dedicated to the unit/automated testing effort, to avoid clogging openssl-dev. Membership is open to whoever wishes to join, even if only to lurk. Ideally all testing discussions will eventually move to openssl-dev once we have processes, tools, conventions, etc. in place.
 == Team ==

← Older revision		Revision as of 17:39, 6 June 2014
Line 1:		Line 1:
	This page will track the effort to improve unit test and other automated test coverage for OpenSSL. Everyone is encouraged to help with this effort, but this page will track which community members have accepted specific responsibilities, and what tasks are currently underway.		This page will track the effort to improve unit test and other automated test coverage for OpenSSL. Everyone is encouraged to help with this effort, but this page will track which community members have accepted specific responsibilities, and what tasks are currently underway.
		+
		+	== Discussion List ==
		+	[https://groups.google.com/forum/#!forum/openssl-testing openssl-testing] is the mailing list dedicated to the unit/automated testing effort, to avoid clogging openssl-dev. Membership is open to whoever wishes to join, even if only to lurk. Ideally all testing discussions will eventually move to openssl-dev once we have processes, tools, conventions, etc. in place.

	== Team ==		== Team ==