Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2018-08-24T14:34:18Z

Xma21: /* Writing effective Use Cases */

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on MVC. If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [http://www.gatherspace.com/static/use_case_example.html Writing Effective Use Cases].[5]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=How to Write a Use Case?=

==Writing Effective Use Cases==

One of the most difficult problem in software development is capturing precisely what you want to build. Inaccurate requirement will end-up with significant delay, rework or even abandonment of the project. Effective applying use case technique helps your team capturing requirements in user point of view which can be easily understood by both the end-user and your team. Use case driven development support subsequent development activities such as analysis and design and testing.

Listed below are useful links in understanding how to write effective use cases.
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing Effective Use Cases]

=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [http://alistair.cockburn.us/images/Uctempla.doc Basic Use Case Template]
* [5] [http://www.gatherspace.com/static/use_case_example.html#1 Writing Effective Use Cases]

=External Links=

* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2018-08-24T14:33:55Z

Xma21: /* References */

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on MVC. If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [http://www.gatherspace.com/static/use_case_example.html Writing Effective Use Cases].[5]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=How to Write a Use Case?=

==Writing effective Use Cases==

One of the most difficult problem in software development is capturing precisely what you want to build. Inaccurate requirement will end-up with significant delay, rework or even abandonment of the project. Effective applying use case technique helps your team capturing requirements in user point of view which can be easily understood by both the end-user and your team. Use case driven development support subsequent development activities such as analysis and design and testing.

Listed below are useful links in understanding how to write effective use cases.
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]

=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [http://alistair.cockburn.us/images/Uctempla.doc Basic Use Case Template]
* [5] [http://www.gatherspace.com/static/use_case_example.html#1 Writing Effective Use Cases]

=External Links=

* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2018-08-24T14:32:50Z

Xma21: /* References */

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on MVC. If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [http://www.gatherspace.com/static/use_case_example.html Writing Effective Use Cases].[5]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=How to Write a Use Case?=

==Writing effective Use Cases==

One of the most difficult problem in software development is capturing precisely what you want to build. Inaccurate requirement will end-up with significant delay, rework or even abandonment of the project. Effective applying use case technique helps your team capturing requirements in user point of view which can be easily understood by both the end-user and your team. Use case driven development support subsequent development activities such as analysis and design and testing.

Listed below are useful links in understanding how to write effective use cases.
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]

=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [http://alistair.cockburn.us/images/Uctempla.doc Basic Use Case Template]
* [5] [http://www.gatherspace.com/static/use_case_example.html#1 Writing Effective Use Cases]
* [6] [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]

=External Links=

* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2018-08-24T14:32:13Z

Xma21: /* External Links */

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on MVC. If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [http://www.gatherspace.com/static/use_case_example.html Writing Effective Use Cases].[5]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=How to Write a Use Case?=

==Writing effective Use Cases==

One of the most difficult problem in software development is capturing precisely what you want to build. Inaccurate requirement will end-up with significant delay, rework or even abandonment of the project. Effective applying use case technique helps your team capturing requirements in user point of view which can be easily understood by both the end-user and your team. Use case driven development support subsequent development activities such as analysis and design and testing.

Listed below are useful links in understanding how to write effective use cases.
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]

=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [http://alistair.cockburn.us/images/Uctempla.doc Basic Use Case Template]
* [5] [http://www.gatherspace.com/static/use_case_example.html#1 Writing Effective Use Cases]
* [6] [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

=External Links=

* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2018-08-24T14:31:11Z

Xma21: /* Writing effective Use Cases */

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on MVC. If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [http://www.gatherspace.com/static/use_case_example.html Writing Effective Use Cases].[5]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=How to Write a Use Case?=

==Writing effective Use Cases==

One of the most difficult problem in software development is capturing precisely what you want to build. Inaccurate requirement will end-up with significant delay, rework or even abandonment of the project. Effective applying use case technique helps your team capturing requirements in user point of view which can be easily understood by both the end-user and your team. Use case driven development support subsequent development activities such as analysis and design and testing.

Listed below are useful links in understanding how to write effective use cases.
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]

=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [http://alistair.cockburn.us/images/Uctempla.doc Basic Use Case Template]
* [5] [http://www.gatherspace.com/static/use_case_example.html#1 Writing Effective Use Cases]
* [6] [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

=External Links=

* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2018-08-24T14:29:49Z

Xma21: /* How to Write a Use Case */

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on MVC. If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [http://www.gatherspace.com/static/use_case_example.html Writing Effective Use Cases].[5]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=How to Write a Use Case?=

==Writing effective Use Cases==

One of the most difficult problem in software development is capturing precisely what you want to build. Inaccurate requirement will end-up with significant delay, rework or even abandonment of the project. Effective applying use case technique helps your team capturing requirements in user point of view which can be easily understood by both the end-user and your team. Use case driven development support subsequent development activities such as analysis and design and testing.

* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]

=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [http://alistair.cockburn.us/images/Uctempla.doc Basic Use Case Template]
* [5] [http://www.gatherspace.com/static/use_case_example.html#1 Writing Effective Use Cases]
* [6] [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

=External Links=

* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2018-08-24T14:27:35Z

Xma21: /* Writing effective Use Cases */

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on MVC. If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [http://www.gatherspace.com/static/use_case_example.html Writing Effective Use Cases].[5]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=How to Write a Use Case=

==Writing effective Use Cases==

Most of the time it is found that common behavior is replicated in Use Cases. This can be handled by writing Use Cases with basic behavior which can be 'plugged-in' to write use cases which cover more behavior. This makes them reusable from one project to another.

<blockquote> "''A pluggable use case is written in a generic form such that it may be exercised wherever needed. As the name implies a pluggable use case can be ‘plugged’ into any other use case even another pluggable use case. It contains a cohesive set of functionality that encapsulates the common behavior of a subgoal, where this subgoal exists in multiple transactions. Because a pluggable use case only constitutes a subgoal of another use case its context must be inferred from the invoking use case."'' [6]</blockquote>

The following link gives a detailed description of this concept

* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]

=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [http://alistair.cockburn.us/images/Uctempla.doc Basic Use Case Template]
* [5] [http://www.gatherspace.com/static/use_case_example.html#1 Writing Effective Use Cases]
* [6] [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

=External Links=

* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2018-08-24T14:22:18Z

Xma21: /* Advanced Concepts on Use Cases */

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on MVC. If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [http://www.gatherspace.com/static/use_case_example.html Writing Effective Use Cases].[5]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=Writing effective Use Cases=

==Pluggable Use Cases==

Most of the time it is found that common behavior is replicated in Use Cases. This can be handled by writing Use Cases with basic behavior which can be 'plugged-in' to write use cases which cover more behavior. This makes them reusable from one project to another.

<blockquote> "''A pluggable use case is written in a generic form such that it may be exercised wherever needed. As the name implies a pluggable use case can be ‘plugged’ into any other use case even another pluggable use case. It contains a cohesive set of functionality that encapsulates the common behavior of a subgoal, where this subgoal exists in multiple transactions. Because a pluggable use case only constitutes a subgoal of another use case its context must be inferred from the invoking use case."'' [6]</blockquote>

The following link gives a detailed description of this concept

* [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [http://alistair.cockburn.us/images/Uctempla.doc Basic Use Case Template]
* [5] [http://www.gatherspace.com/static/use_case_example.html#1 Writing Effective Use Cases]
* [6] [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

=External Links=

* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2018-08-24T13:34:11Z

Xma21: /* External Links */

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on MVC. If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [http://www.gatherspace.com/static/use_case_example.html Writing Effective Use Cases].[5]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=Advanced Concepts on Use Cases=

==Pluggable Use Cases==

Most of the time it is found that common behavior is replicated in Use Cases. This can be handled by writing Use Cases with basic behavior which can be 'plugged-in' to write use cases which cover more behavior. This makes them reusable from one project to another.

<blockquote> "''A pluggable use case is written in a generic form such that it may be exercised wherever needed. As the name implies a pluggable use case can be ‘plugged’ into any other use case even another pluggable use case. It contains a cohesive set of functionality that encapsulates the common behavior of a subgoal, where this subgoal exists in multiple transactions. Because a pluggable use case only constitutes a subgoal of another use case its context must be inferred from the invoking use case."'' [6]</blockquote>

The following link gives a detailed description of this concept

* [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [http://alistair.cockburn.us/images/Uctempla.doc Basic Use Case Template]
* [5] [http://www.gatherspace.com/static/use_case_example.html#1 Writing Effective Use Cases]
* [6] [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

=External Links=

* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2018-08-24T13:24:29Z

Xma21: /* Definition */

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on MVC. If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [http://www.gatherspace.com/static/use_case_example.html Writing Effective Use Cases].[5]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=Advanced Concepts on Use Cases=

==Pluggable Use Cases==

Most of the time it is found that common behavior is replicated in Use Cases. This can be handled by writing Use Cases with basic behavior which can be 'plugged-in' to write use cases which cover more behavior. This makes them reusable from one project to another.

<blockquote> "''A pluggable use case is written in a generic form such that it may be exercised wherever needed. As the name implies a pluggable use case can be ‘plugged’ into any other use case even another pluggable use case. It contains a cohesive set of functionality that encapsulates the common behavior of a subgoal, where this subgoal exists in multiple transactions. Because a pluggable use case only constitutes a subgoal of another use case its context must be inferred from the invoking use case."'' [6]</blockquote>

The following link gives a detailed description of this concept

* [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [http://alistair.cockburn.us/images/Uctempla.doc Basic Use Case Template]
* [5] [http://www.gatherspace.com/static/use_case_example.html#1 Writing Effective Use Cases]
* [6] [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

=External Links=

* [http://alistair.cockburn.us/index.php/Use_case_fundamentals Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-05-08T17:27:24Z

Xma21: /* Table */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran (srajend@ncsu.edu)

2. Xiao Ma (xma21@ncsu.edu)

3. Zekun Zhang (zzhang56@ncsu.edu)

4. Zhiyu Chen (zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===
* [http://wiki.expertiza.ncsu.edu/index.php/Users Table of User model]

=== Methods ===
1. index

This method is used to list users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

3. set_anonymized_view

This method is used to anonymize the usernames in the views for demo purposes.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request3.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place" 
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


3. set_anonymized_view


3.1 "The method should add the session ip to the list of anonymized ip's and redirect to the previous page "


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This is tested by the same test for index"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page" 
6.2 "check if the user is not available for editing, will it redirect to users/list page" 
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home" 
7.2 "if the user is valid, check the return value"


8. new


8.1 "check if this will render users/new page"


9. request_new


9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."


10. create


10.1 "Is the name new? If yes, good. Otherwise, register the user by email address." 
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"


11. create_requested_user_record


11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution." 
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."


12. create_approved_user


12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject." 
12.2 "is the status Approved or Rejected?" 
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail" 
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."


13. edit


13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."


14. update


14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page. 
14.2 "When user is not updated successfully, it redirects to users/edit page."


15. destroy


15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)


16. keys


16.1 "When params[:id] is not nil, @private_key gets correct value." 
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."


== Test Result ==

Coverage percentage:

[[File:E1823_Test_Result.png]]

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-05-08T17:25:47Z

Xma21: /* Table */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran (srajend@ncsu.edu)

2. Xiao Ma (xma21@ncsu.edu)

3. Zekun Zhang (zzhang56@ncsu.edu)

4. Zhiyu Chen (zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===
* [http://wiki.expertiza.ncsu.edu/index.php/Main_Page Main Page Expertiza]
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who created the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

3. set_anonymized_view

This method is used to anonymize the usernames in the views for demo purposes.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request3.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place" 
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


3. set_anonymized_view


3.1 "The method should add the session ip to the list of anonymized ip's and redirect to the previous page "


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This is tested by the same test for index"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page" 
6.2 "check if the user is not available for editing, will it redirect to users/list page" 
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home" 
7.2 "if the user is valid, check the return value"


8. new


8.1 "check if this will render users/new page"


9. request_new


9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."


10. create


10.1 "Is the name new? If yes, good. Otherwise, register the user by email address." 
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"


11. create_requested_user_record


11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution." 
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."


12. create_approved_user


12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject." 
12.2 "is the status Approved or Rejected?" 
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail" 
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."


13. edit


13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."


14. update


14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page. 
14.2 "When user is not updated successfully, it redirects to users/edit page."


15. destroy


15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)


16. keys


16.1 "When params[:id] is not nil, @private_key gets correct value." 
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."


== Test Result ==

Coverage percentage:

[[File:E1823_Test_Result.png]]

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T02:26:43Z

Xma21: /* Test Result */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

3. set_anonymized_view

This method is used to anonymize the usernames in the views for demo purposes.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request3.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place" 
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


3. set_anonymized_view


3.1 "The method should add the session ip to the list of anonymized ip's and redirect to the previous page "


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This is tested by the same test for index"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page" 
6.2 "check if the user is not available for editing, will it redirect to users/list page" 
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home" 
7.2 "if the user is valid, check the return value"


8. new


8.1 "check if this will render users/new page"


9. request_new


9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."


10. create


10.1 "Is the name new? If yes, good. Otherwise, register the user by email address." 
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"


11. create_requested_user_record


11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution." 
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."


12. create_approved_user


12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject." 
12.2 "is the status Approved or Rejected?" 
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail" 
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."


13. edit


13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."


14. update


14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page. 
14.2 "When user is not updated successfully, it redirects to users/edit page."


15. destroy


15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)


16. keys


16.1 "When params[:id] is not nil, @private_key gets correct value." 
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."


== Test Result ==

Coverage percentage:

[[File:E1823_Test_Result.png]]

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T02:26:02Z

Xma21: /* Test Result */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

3. set_anonymized_view

This method is used to anonymize the usernames in the views for demo purposes.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request3.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place" 
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


3. set_anonymized_view


3.1 "The method should add the session ip to the list of anonymized ip's and redirect to the previous page "


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This is tested by the same test for index"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page" 
6.2 "check if the user is not available for editing, will it redirect to users/list page" 
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home" 
7.2 "if the user is valid, check the return value"


8. new


8.1 "check if this will render users/new page"


9. request_new


9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."


10. create


10.1 "Is the name new? If yes, good. Otherwise, register the user by email address." 
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"


11. create_requested_user_record


11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution." 
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."


12. create_approved_user


12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject." 
12.2 "is the status Approved or Rejected?" 
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail" 
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."


13. edit


13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."


14. update


14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page. 
14.2 "When user is not updated successfully, it redirects to users/edit page."


15. destroy


15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)


16. keys


16.1 "When params[:id] is not nil, @private_key gets correct value." 
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."


== Test Result ==

Coverage:

[[File:E1823_Test_Result.png]]

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T02:25:51Z

Xma21:

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

3. set_anonymized_view

This method is used to anonymize the usernames in the views for demo purposes.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request3.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place" 
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


3. set_anonymized_view


3.1 "The method should add the session ip to the list of anonymized ip's and redirect to the previous page "


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This is tested by the same test for index"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page" 
6.2 "check if the user is not available for editing, will it redirect to users/list page" 
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home" 
7.2 "if the user is valid, check the return value"


8. new


8.1 "check if this will render users/new page"


9. request_new


9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."


10. create


10.1 "Is the name new? If yes, good. Otherwise, register the user by email address." 
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"


11. create_requested_user_record


11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution." 
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."


12. create_approved_user


12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject." 
12.2 "is the status Approved or Rejected?" 
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail" 
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."


13. edit


13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."


14. update


14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page. 
14.2 "When user is not updated successfully, it redirects to users/edit page."


15. destroy


15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)


16. keys


16.1 "When params[:id] is not nil, @private_key gets correct value." 
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."


== Test Result ==

Coverage:
[[File:E1823_Test_Result.png]]

File:E1823 Test Result.png

2018-04-25T02:24:39Z

Xma21:

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T01:40:06Z

Xma21:

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request3.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place" 
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page" 
6.2 "check if the user is not available for editing, will it redirect to users/list page" 
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home" 
7.2 "if the user is valid, check the return value"


8. new


8.1 "check if this will render users/new page"


9. request_new


9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."


10. create


10.1 "Is the name new? If yes, good. Otherwise, register the user by email address." 
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"


11. create_requested_user_record


11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution." 
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."


12. create_approved_user


12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject." 
12.2 "is the status Approved or Rejected?" 
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail" 
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."


13. edit


13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."


14. update


14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page. 
14.2 "When user is not updated successfully, it redirects to users/edit page."


15. destroy


15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)


16. keys


16.1 "When params[:id] is not nil, @private_key gets correct value." 
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."

== Test Result ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:56:31Z

Xma21: /* References */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request3.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place" 
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page" 
6.2 "check if the user is not available for editing, will it redirect to users/list page" 
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home" 
7.2 "if the user is valid, check the return value"


8. new


8.1 "check if this will render users/new page"


9. request_new


9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."


10. create


10.1 "Is the name new? If yes, good. Otherwise, register the user by email address." 
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"


11. create_requested_user_record


11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution." 
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."


12. create_approved_user


12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject." 
12.2 "is the status Approved or Rejected?" 
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail" 
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."


13. edit


13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."


14. update


14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page. 
14.2 "When user is not updated successfully, it redirects to users/edit page."


15. destroy


15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)


16. keys


16.1 "When params[:id] is not nil, @private_key gets correct value." 
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:55:30Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request3.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place" 
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page" 
6.2 "check if the user is not available for editing, will it redirect to users/list page" 
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home" 
7.2 "if the user is valid, check the return value"


8. new


8.1 "check if this will render users/new page"


9. request_new


9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."


10. create


10.1 "Is the name new? If yes, good. Otherwise, register the user by email address." 
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"


11. create_requested_user_record


11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution." 
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."


12. create_approved_user


12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject." 
12.2 "is the status Approved or Rejected?" 
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail" 
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."


13. edit


13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."


14. update


14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page. 
14.2 "When user is not updated successfully, it redirects to users/edit page."


15. destroy


15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)


16. keys


16.1 "When params[:id] is not nil, @private_key gets correct value." 
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."


== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:53:54Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request3.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place" 
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page" 
6.2 "check if the user is not available for editing, will it redirect to users/list page" 
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home" 
7.2 "if the user is valid, check the return value"


8. new


8.1 "check if this will render users/new page"


9. request_new


9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."


10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:52:07Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request2.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place" 
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page"
6.2 "check if the user is not available for editing, will it redirect to users/list page"
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, check the return value"


8. new

<pre>
8.1 "check if this will render users/new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:51:26Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request2.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place"

1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page"
6.2 "check if the user is not available for editing, will it redirect to users/list page"
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, check the return value"


8. new

<pre>
8.1 "check if this will render users/new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:51:09Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request2.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page"
6.2 "check if the user is not available for editing, will it redirect to users/list page"
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, check the return value"


8. new

<pre>
8.1 "check if this will render users/new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:50:31Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page"
6.2 "check if the user is not available for editing, will it redirect to users/list page"
6.3 "check if the user is available for editing, will it render users/show page"


7. show

<pre>
7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, check the return value"
</pre>

8. new

<pre>
8.1 "check if this will render users/new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:49:32Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


4. list

<pre>
4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"
</pre>

5. list_pending_requested

<pre>
5.1 "check if it will render users/list_pending_requested page"
</pre>

6. show_selection

<pre>
6.1 "check if the user is nil, will the page redirect to users/list page"
6.2 "check if the user is not available for editing, will it redirect to users/list page"
6.3 "check if the user is available for editing, will it render users/show page"
</pre>

7. show

<pre>
7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, check the return value"
</pre>

8. new

<pre>
8.1 "check if this will render users/new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:49:06Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name

<pre>
2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"
</pre>

4. list

<pre>
4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"
</pre>

5. list_pending_requested

<pre>
5.1 "check if it will render users/list_pending_requested page"
</pre>

6. show_selection

<pre>
6.1 "check if the user is nil, will the page redirect to users/list page"
6.2 "check if the user is not available for editing, will it redirect to users/list page"
6.3 "check if the user is available for editing, will it render users/show page"
</pre>

7. show

<pre>
7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, check the return value"
</pre>

8. new

<pre>
8.1 "check if this will render users/new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:45:57Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index

<pre>
1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"
</pre>

2. auto_complete_for_user_name

<pre>
2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"
</pre>

4. list

<pre>
4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"
</pre>

5. list_pending_requested

<pre>
5.1 "request_users should contain all the RequestUsers and roles should contain all the roles, just check if it will render list page"
</pre>

6. show_selection

<pre>
6.1 "check if the user is nil, will the page redirect to list"
6.2 "check if the user is not available for editing, will it redirect to list"
6.3 "check if the user is available for editing, will it render show"
</pre>

7. show

<pre>
7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, just check the return value"
</pre>

8. new

<pre>
8.1 "just need to check if this will render new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:45:36Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index

</pre>
1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"
</pre>

2. auto_complete_for_user_name

<pre>
2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"
</pre>

4. list

<pre>
4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"
</pre>

5. list_pending_requested

<pre>
5.1 "request_users should contain all the RequestUsers and roles should contain all the roles, just check if it will render list page"
</pre>

6. show_selection

<pre>
6.1 "check if the user is nil, will the page redirect to list"
6.2 "check if the user is not available for editing, will it redirect to list"
6.3 "check if the user is available for editing, will it render show"
</pre>

7. show

<pre>
7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, just check the return value"
</pre>

8. new

<pre>
8.1 "just need to check if this will render new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:44:47Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index

1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"

2. auto_complete_for_user_name

<pre>
2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"
</pre>

4. list

<pre>
4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"
</pre>

5. list_pending_requested

<pre>
5.1 "request_users should contain all the RequestUsers and roles should contain all the roles, just check if it will render list page"
</pre>

6. show_selection

<pre>
6.1 "check if the user is nil, will the page redirect to list"
6.2 "check if the user is not available for editing, will it redirect to list"
6.3 "check if the user is available for editing, will it render show"
</pre>

7. show

<pre>
7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, just check the return value"
</pre>

8. new

<pre>
8.1 "just need to check if this will render new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence.
So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:43:53Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index

<pre>
1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"
</pre>

2. auto_complete_for_user_name

<pre>
2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"
</pre>

4. list

<pre>
4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user.
This will be checked for all the different user types"
</pre>

5. list_pending_requested

<pre>
5.1 "request_users should contain all the RequestUsers and roles should contain all the roles, just check if it will render list page"
</pre>

6. show_selection

<pre>
6.1 "check if the user is nil, will the page redirect to list"
6.2 "check if the user is not available for editing, will it redirect to list"
6.3 "check if the user is available for editing, will it render show"
</pre>

7. show

<pre>
7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, just check the return value"
</pre>

8. new

<pre>
8.1 "just need to check if this will render new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence.
So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T00:43:03Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index

<pre>
1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"
</pre>

2. auto_complete_for_user_name

<pre>
2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"
</pre>

4. list

<pre>
4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user.
This will be checked for all the different user types"
</pre>

5. list_pending_requested

<pre>
5.1 "request_users should contain all the RequestUsers and roles should contain all the roles, just check if it will render list page"
</pre>

6. show_selection

<pre>
6.1 "check if the user is nil, will the page redirect to list"
6.2 "check if the user is not available for editing, will it redirect to list"
6.3 "check if the user is available for editing, will it render show"
</pre>

7. show

<pre>
7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, just check the return value"
</pre>

8. new

<pre>
8.1 "just need to check if this will render new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-13T02:03:35Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb

app/views/users/keys.html.erb

app/views/users/list.html.erb

app/views/users/list_pending_requested.erb

app/views/users/new.html.erb

app/views/users/request_new.html.erb

app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index

<pre>
1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"
</pre>

2. auto_complete_for_user_name

<pre>
2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"
</pre>

4. list

<pre>
4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"
</pre>

5. list_pending_requested

<pre>
5.1 "request_users should contain all the RequestUsers and roles should contain all the roles, just check if it will render list page"
</pre>

6. show_selection

<pre>
6.1 "check if the user is nil, will the page redirect to list"
6.2 "check if the user is not available for editing, will it redirect to list"
6.3 "check if the user is available for editing, will it render show"
</pre>

7. show

<pre>
7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, just check the return value"
</pre>

8. new

<pre>
8.1 "just need to check if this will render new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-13T02:01:56Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb

app/views/users/keys.html.erb

app/views/users/list.html.erb

app/views/users/list_pending_requested.erb

app/views/users/new.html.erb

app/views/users/request_new.html.erb

app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index

<pre>
1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"
</pre>

2. auto_complete_for_user_name

<pre>
2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"
</pre>

4. list

<pre>
4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"
</pre>

5. list_pending_requested

<pre>
5.1 "request_users should contain all the RequestUsers and roles should contain all the roles, just check if it will render list page"
</pre>

6. show_selection

<pre>
6.1 "check if the user is nil, will the page redirect to list"
6.2 "check if the user is not available for editing, will it redirect to list"
6.3 "check if the user is available for editing, will it render show"
</pre>

7. show

<pre>
7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, just check the return value"
</pre>

8. new

<pre>
8.1 "just need to check if this will render new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This condition also covers the condition that user is deleted successfully it, so)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-13T02:01:28Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb

app/views/users/keys.html.erb

app/views/users/list.html.erb

app/views/users/list_pending_requested.erb

app/views/users/new.html.erb

app/views/users/request_new.html.erb

app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index

<pre>
1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"
</pre>

2. auto_complete_for_user_name

<pre>
2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"
</pre>

4. list

<pre>
4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"
</pre>

5. list_pending_requested

<pre>
5.1 "request_users should contain all the RequestUsers and roles should contain all the roles, just check if it will render list page"
</pre>

6. show_selection

<pre>
6.1 "check if the user is nil, will the page redirect to list"
6.2 "check if the user is not available for editing, will it redirect to list"
6.3 "check if the user is available for editing, will it render show"
</pre>

7. show

<pre>
7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, just check the return value"
</pre>

8. new

<pre>
8.1 "just need to check if this will render new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "When user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page." (This condition also covers the condition that user is deleted successfully it, so)
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-13T01:44:08Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb

app/views/users/keys.html.erb

app/views/users/list.html.erb

app/views/users/list_pending_requested.erb

app/views/users/new.html.erb

app/views/users/request_new.html.erb

app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index

<pre>
1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"
</pre>

2. auto_complete_for_user_name

<pre>
2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"
</pre>

4. list

<pre>
4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"
</pre>

5. list_pending_requested

<pre>
5.1 "request_users should contain all the RequestUsers and roles should contain all the roles, just check if it will render list page"
</pre>

6. show_selection

<pre>
6.1 "check if the user is nil, will the page redirect to list"
6.2 "check if the user is not available for editing, will it redirect to list"
6.3 "check if the user is available for editing, will it render show"
</pre>

7. show

<pre>
7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, just check the return value"
</pre>

8. new

<pre>
8.1 "just need to check if this will render new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page."
14.2 "when user is not updated successfully, it redirects to users/edit page."
</pre>

15. destroy

<pre>
15 "If the attributes of users are successfully updated, check whether it shows the correct flash and redirects to users#show page after updating."
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "when params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-13T01:40:43Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb

app/views/users/keys.html.erb

app/views/users/list.html.erb

app/views/users/list_pending_requested.erb

app/views/users/new.html.erb

app/views/users/request_new.html.erb

app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index

<pre>
1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"
</pre>

2. auto_complete_for_user_name

<pre>
2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"
</pre>

4. list

<pre>
4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"
</pre>

5. list_pending_requested

<pre>
5.1 "request_users should contain all the RequestUsers and roles should contain all the roles, just check if it will render list page"
</pre>

6. show_selection

<pre>
6.1 "check if the user is nil, will the page redirect to list"
6.2 "check if the user is not available for editing, will it redirect to list"
6.3 "check if the user is available for editing, will it render show"
</pre>

7. show

<pre>
7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home"
7.2 "if the user is valid, just check the return value"
</pre>

8. new

<pre>
8.1 "just need to check if this will render new page"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "If the attributes of users are successfully updated, check whether it shows the correct flash and redirects to users#show page after updating."
14.2 "If the attributes of users are not successfully updated, check whether it renders users#edit page."
</pre>

15. destroy

<pre>
15 "If the attributes of users are successfully updated, check whether it shows the correct flash and redirects to users#show page after updating."
</pre>

16. keys

<pre>
16.1 "When params[:id] is not nil, @private_key gets correct value."
16.2 "when params[:id] is nil, it redirects to /tree_display/drill page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-08T21:42:03Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb

app/views/users/keys.html.erb

app/views/users/list.html.erb

app/views/users/list_pending_requested.erb

app/views/users/new.html.erb

app/views/users/request_new.html.erb

app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

3. set_anonymized_view

4. list

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtain all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detect if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

8. new

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "If the attributes of users are successfully updated, check whether it shows the correct flash and redirects to users#show page after updating."
14.2 "If the attributes of users are not successfully updated, check whether it renders users#edit page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-08T21:38:12Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb

app/views/users/keys.html.erb

app/views/users/list.html.erb

app/views/users/list_pending_requested.erb

app/views/users/new.html.erb

app/views/users/request_new.html.erb

app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

3. set_anonymized_view

4. list

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtain all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detect if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

8. new

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "If successfully updates the attributes of users, check whether it shows the correct flash and redirects to users#show page after updating."
14.2 "If fails to update the attributes of users, check whether it renders users#edit page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-08T21:37:28Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb

app/views/users/keys.html.erb

app/views/users/list.html.erb

app/views/users/list_pending_requested.erb

app/views/users/new.html.erb

app/views/users/request_new.html.erb

app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

3. set_anonymized_view

4. list

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtain all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detect if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

8. new

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
"Here isn't any conditional sentence, so just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "If successfully updates the attributes of users, check whether it shows the correct flash and redirects to users#show page after updating."

14.2 "If fails to update the attributes of users, check whether it renders users#edit page."

</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-08T21:33:00Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb

app/views/users/keys.html.erb

app/views/users/list.html.erb

app/views/users/list_pending_requested.erb

app/views/users/new.html.erb

app/views/users/request_new.html.erb

app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

3. set_anonymized_view

4. list

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtain all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detect if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

8. new

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence. So only need to check whether it renders users#edit page"
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-08T21:31:53Z

Xma21: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb

app/views/users/keys.html.erb

app/views/users/list.html.erb

app/views/users/list_pending_requested.erb

app/views/users/new.html.erb

app/views/users/request_new.html.erb

app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

3. set_anonymized_view

4. list

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtain all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detect if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

8. new

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

<pre>
13.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-07T03:23:25Z

Xma21: /* Methods */

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-07T03:22:50Z

Xma21: /* Methods */

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-06T15:01:04Z

Xma21: /* Methods */

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-06T03:53:19Z

Xma21: /* Methods */

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-06T03:52:07Z

Xma21: /* Methods */

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-06T03:51:48Z

Xma21: /* Methods */

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-06T03:28:11Z

Xma21: /* Methods */

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-06T03:25:56Z

Xma21: /* Methods */

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-06T02:28:16Z

Xma21: /* Methods */