Skip to content

Commit 3c09517

Browse files
sanoursasanoursa
committed
Current snapshot of GVFS
0 parents  commit 3c09517

File tree

328 files changed

+38997
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

328 files changed

+38997
-0
lines changed

‎.gitattributes

+4
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
###############################################################################
2+
# Do not normalize any line endings.
3+
###############################################################################
4+
* -text

‎.gitignore

+218
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,218 @@
1+
## Ignore Visual Studio temporary files, build results, and
2+
## files generated by popular Visual Studio add-ons.
3+
4+
# User-specific files
5+
*.suo
6+
*.user
7+
*.userosscache
8+
*.sln.docstates
9+
10+
# User-specific files (MonoDevelop/Xamarin Studio)
11+
*.userprefs
12+
13+
# Build results
14+
[Dd]ebug/
15+
[Dd]ebugPublic/
16+
[Rr]elease/
17+
[Rr]eleases/
18+
x64/
19+
x86/
20+
build/
21+
bld/
22+
[Bb]in/
23+
[Oo]bj/
24+
25+
# Visual Studio 2015 cache/options directory
26+
.vs/
27+
28+
# MSTest test Results
29+
[Tt]est[Rr]esult*/
30+
[Bb]uild[Ll]og.*
31+
32+
# NUNIT
33+
*.VisualState.xml
34+
TestResult.xml
35+
36+
# Build Results of an ATL Project
37+
[Dd]ebugPS/
38+
[Rr]eleasePS/
39+
dlldata.c
40+
41+
# DNX
42+
project.lock.json
43+
artifacts/
44+
45+
*_i.c
46+
*_p.c
47+
*_i.h
48+
*.ilk
49+
*.meta
50+
*.obj
51+
*.pch
52+
*.pdb
53+
*.pgc
54+
*.pgd
55+
*.rsp
56+
*.sbr
57+
*.tlb
58+
*.tli
59+
*.tlh
60+
*.tmp
61+
*.tmp_proj
62+
*.log
63+
*.vspscc
64+
*.vssscc
65+
.builds
66+
*.pidb
67+
*.svclog
68+
*.scc
69+
70+
# Chutzpah Test files
71+
_Chutzpah*
72+
73+
# Visual C++ cache files
74+
ipch/
75+
*.aps
76+
*.ncb
77+
*.opensdf
78+
*.sdf
79+
*.cachefile
80+
*.VC.opendb
81+
*.VC.db
82+
83+
# Visual Studio profiler
84+
*.psess
85+
*.vsp
86+
*.vspx
87+
88+
# TFS 2012 Local Workspace
89+
$tf/
90+
91+
# Guidance Automation Toolkit
92+
*.gpState
93+
94+
# ReSharper is a .NET coding add-in
95+
_ReSharper*/
96+
*.[Rr]e[Ss]harper
97+
*.DotSettings.user
98+
99+
# JustCode is a .NET coding add-in
100+
.JustCode
101+
102+
# TeamCity is a build add-in
103+
_TeamCity*
104+
105+
# DotCover is a Code Coverage Tool
106+
*.dotCover
107+
108+
# NCrunch
109+
_NCrunch_*
110+
.*crunch*.local.xml
111+
112+
# MightyMoose
113+
*.mm.*
114+
AutoTest.Net/
115+
116+
# Web workbench (sass)
117+
.sass-cache/
118+
119+
# Installshield output folder
120+
[Ee]xpress/
121+
122+
# DocProject is a documentation generator add-in
123+
DocProject/buildhelp/
124+
DocProject/Help/*.HxT
125+
DocProject/Help/*.HxC
126+
DocProject/Help/*.hhc
127+
DocProject/Help/*.hhk
128+
DocProject/Help/*.hhp
129+
DocProject/Help/Html2
130+
DocProject/Help/html
131+
132+
# Click-Once directory
133+
publish/
134+
135+
# Publish Web Output
136+
*.[Pp]ublish.xml
137+
*.azurePubxml
138+
## TODO: Comment the next line if you want to checkin your
139+
## web deploy settings but do note that will include unencrypted
140+
## passwords
141+
#*.pubxml
142+
143+
*.publishproj
144+
145+
# NuGet Packages
146+
*.nupkg
147+
# The packages folder can be ignored because of Package Restore
148+
**/packages/*
149+
# except build/, which is used as an MSBuild target.
150+
!**/packages/build/
151+
# Uncomment if necessary however generally it will be regenerated when needed
152+
#!**/packages/repositories.config
153+
154+
# Windows Azure Build Output
155+
csx/
156+
*.build.csdef
157+
158+
# Windows Store app package directory
159+
AppPackages/
160+
161+
# Visual Studio cache files
162+
# files ending in .cache can be ignored
163+
*.[Cc]ache
164+
# but keep track of directories ending in .cache
165+
!*.[Cc]ache/
166+
167+
# Others
168+
ClientBin/
169+
[Ss]tyle[Cc]op.*
170+
~$*
171+
*~
172+
*.dbmdl
173+
*.dbproj.schemaview
174+
*.pfx
175+
*.publishsettings
176+
node_modules/
177+
orleans.codegen.cs
178+
179+
# RIA/Silverlight projects
180+
Generated_Code/
181+
182+
# Backup & report files from converting an old project file
183+
# to a newer Visual Studio version. Backup files are not needed,
184+
# because we have git ;-)
185+
_UpgradeReport_Files/
186+
Backup*/
187+
UpgradeLog*.XML
188+
UpgradeLog*.htm
189+
190+
# SQL Server files
191+
*.mdf
192+
*.ldf
193+
194+
# Business Intelligence projects
195+
*.rdl.data
196+
*.bim.layout
197+
*.bim_*.settings
198+
199+
# Microsoft Fakes
200+
FakesAssemblies/
201+
202+
# Node.js Tools for Visual Studio
203+
.ntvs_analysis.dat
204+
205+
# Visual Studio 6 build log
206+
*.plg
207+
208+
# Visual Studio 6 workspace options file
209+
*.opt
210+
211+
# LightSwitch generated files
212+
GeneratedArtifacts/
213+
_Pvt_Extensions/
214+
ModelManifest.xml
215+
216+
*.dll
217+
*.cab
218+
*.cer

‎AuthoringTests.md

+59
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
# Authoring Tests
2+
3+
## Functional Tests
4+
5+
### 1. Running the functional tests
6+
7+
Our functional tests are in the GVFS.FunctionalTests project. They are built on NUnit 3, which is available as a set of NuGet packages.
8+
9+
To run the functional tests:
10+
11+
1. Open GVFS.sln in Visual Studio
12+
2. Build all, which will download the NUnit framework and runner
13+
3. You have three options for how to run the tests, all of which are equivalent.
14+
a. Run the GVFS.FunctionalTests project. Even better, set it as the default project and hit F5.
15+
b. Use the command line runner. After building, execute ```Scripts\RunFunctionalTests.bat```
16+
c. If you want to use Visual Studio's Test Explorer, you need to install the NUnit 3 Test Adapter in VS | Tools | Extensions and Updates.
17+
18+
Option 1 is probably the most convenient for developers. Option 2 will be used on the build machines.
19+
20+
The functional tests take a set of parameters that indicate what paths and URLs to work with. If you want to customize those settings, they
21+
can be found in GVFS.FunctionalTests\App.config.
22+
23+
### 2. Running Full Suite of Tests vs. Smoke Tests
24+
25+
By default, the GVFS functional tests run a subset of tests as a quick smoke test for developers. To run all tests, pass in the `--full-suite` flag
26+
27+
### 3. Running specific tests
28+
29+
Specific tests can be run by specifying `--test=<comma separated list of tests>` as the command line arguments to the functional
30+
test project.
31+
32+
### 4. How to write a functional test
33+
34+
Each piece of functionality that we add to GVFS should have corresponding functional tests that clone a repo, mount GVFS, and use existing tools and file system
35+
APIs to interact with the virtual repo.
36+
37+
Since these are functional tests that can potentially modify the state of files on disk, you need to be careful to make sure each test can run in a clean
38+
environment. There are three base classes that you can derive from when writing your tests. It's also important to put your new class into the same namespace
39+
as the base class, because NUnit treats namespaces like test suites, and we have logic that keys off of that for deciding when to create enlistments.
40+
41+
1. TestsWithLongRunningEnlistment
42+
Before any test in this namespace is executed, we create a single enlistment and mount GVFS. We then run all tests in this namespace that derive
43+
from this base class. Only put tests in here that are purely readonly and will leave the repo in a good state for future tests.
44+
45+
2. TestsWithEnlistmentPerFixture
46+
For any test fixture (a fixture is the same as a class in NUnit) that derives from this class, we create an enlistment and mount GVFS before running
47+
any of the tests in the fixture, and then we unmount and delete the enlistment after all tests are done (but before any other fixture runs). If you need
48+
to write a sequence of tests that manipulate the same repo, this is the right base class.
49+
50+
3. TestsWithEnlistmentPerTestCase
51+
Derive from this class if you need a brand new enlistment per test case. This is the most reliable, but also most expensive option.
52+
53+
### 5. Updating the remote test branch
54+
55+
By default, GVFS.FunctionalTests clones master, checks out the branch "FunctionalTests/YYYYMMDD" (with the day the FunctionalTests branch was created),
56+
and then removes all remote tracking information. This is done to guarantee that remote changes to tip cannot break functional tests. If you need to update
57+
the functional tests to use a new FunctionalTests branch, you'll need to create a new "FunctionalTests/YYYYMMDD" branch and update the 'Commitish' setting in App.Config,
58+
and the project properties (Settings.Designer.cs, and Settings.settings) to have this new branch name.
59+
Once you have verified your scenarios locally you can push the new FuncationTests branch and then your changes.

0 commit comments

Comments
 (0)