You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
linkTitle: ".NET Assemblies Are Now Strongly Signed"
4
+
date: 2026-04-27
5
+
tags: ["selenium", "dotnet"]
6
+
categories: ["general"]
7
+
author: Nikolay Borisenko [@nvborisenko](https://github.com/nvborisenko)
8
+
description: >
9
+
Starting with Selenium 4.44, the main NuGet packages ship strongly signed assemblies. The separate StrongNamed packages are retired.
10
+
---
11
+
12
+
Starting with **Selenium 4.44**, the `Selenium.WebDriver` and `Selenium.Support` NuGet packages ship **strongly signed assemblies**. The separate `Selenium.WebDriver.StrongNamed` and `Selenium.Support.StrongNamed` packages are discontinued.
13
+
14
+
## Why This Matters
15
+
16
+
Without strong naming on the official packages, any project that itself needed to be strongly signed could not reference Selenium from NuGet. Teams were forced to either forgo strong naming, bundle out-of-band downloads, or use the separate `StrongNamed` packages with a different assembly name — all of which caused friction, especially in enterprise environments.
17
+
18
+
## What Changed
19
+
20
+
-`Selenium.WebDriver` and `Selenium.Support` are now strongly signed.
If you use the regular packages — the assemblies are now signed but the assembly names change (`WebDriver.dll` → `Selenium.WebDriver.dll`, `WebDriver.Support.dll` → `Selenium.Support.dll`), so update any explicit assembly references accordingly. The public API is unchanged.
34
+
35
+
## Related Issues
36
+
37
+
-[#12315](https://github.com/SeleniumHQ/selenium/issues/12315) — Publish StrongNamed builds to NuGet feed
38
+
-[#10845](https://github.com/SeleniumHQ/selenium/issues/10845) — Revisiting strong-named assemblies for NuGet
39
+
-[#14115](https://github.com/SeleniumHQ/selenium/issues/14115) — Strong Name Key
Copy file name to clipboardExpand all lines: website_and_docs/content/documentation/test_practices/testing_types.en.md
+63-54Lines changed: 63 additions & 54 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,9 +9,10 @@ aliases: [
9
9
---
10
10
11
11
### Acceptance testing
12
+
12
13
This type of testing is done to determine if a feature or system
13
-
meets the customer expectations and requirements.
14
-
This type of testing generally involves the customer's
14
+
meets the customer expectations and requirements.
15
+
This type of testing generally involves the customer's
15
16
cooperation or feedback, being a validation activity that
16
17
answers the question:
17
18
>Are we building the **_right_** product?
@@ -22,24 +23,25 @@ This simulation could be done by record/playback or through the
22
23
different supported languages as explained in this documentation.
23
24
Note: Acceptance testing is a subtype of **_functional testing_**,
24
25
which some people might also refer to.
25
-
26
+
26
27
### Functional testing
28
+
27
29
This type of testing is done to determine if a
28
30
feature or system functions properly without issues. It checks
29
31
the system at different levels to ensure that all scenarios
30
-
are covered and that the system does _what_ it's
32
+
are covered and that the system does _what_ it's
31
33
supposed to do. It's a verification activity that
32
34
answers the question:
33
35
>Are we building the product **_right?_**
34
-
35
-
This generally includes: the tests work without errors
36
-
(404, exceptions...), in a usable way (correct redirections),
37
-
in an accessible way and matching its specifications
36
+
37
+
This generally includes: the tests work without errors
38
+
(404, exceptions...), in a usable way (correct redirections),
39
+
in an accessible way and matching its specifications
38
40
(see **_acceptance testing_** above).
39
41
40
42
For web applications, the automation of this testing can be
41
-
done directly with Selenium by simulating expected returns.
42
-
This simulation could be done by record/playback or through
43
+
done directly with Selenium by simulating expected returns.
44
+
This simulation could be done by record/playback or through
43
45
the different supported languages as explained in this documentation.
44
46
45
47
### Integration Tests
@@ -53,93 +55,100 @@ System Testing is a complete fully integrated product Testing. It is an end-to-e
53
55
>For example, **_Testing the end to end flow from login to placing an order and rechecking the order in My Orders page and logoff from an ecommerce website._**
54
56
55
57
### Performance testing
56
-
As its name indicates, performance tests are done
58
+
59
+
As its name indicates, performance tests are done
57
60
to measure how well an application is performing.
58
61
59
62
There are two main sub-types for performance testing:
60
63
61
64
#### Load testing
62
-
Load testing is done to verify how well the
63
-
application works under different defined loads
65
+
66
+
Load testing is done to verify how well the
67
+
application works under different defined loads
64
68
(usually a particular number of users connected at once).
65
69
66
70
>For example, **_Testing that the site can handle numerous orders/users at once._**
67
71
68
72
#### Stress testing
73
+
69
74
Stress testing is done to verify how well the
70
75
application works under stress (or above the maximum supported load).
71
76
72
77
>For example, **_Testing that your ecommerce site can handle Black Friday_**
73
78
74
-
Generally, performance tests are done by executing some
75
-
Selenium written tests simulating different users
76
-
hitting a particular function on the web app and
77
-
retrieving some meaningful measurements.
79
+
Generally, performance tests are done by executing some
80
+
Selenium written tests simulating different users
81
+
hitting a particular function on the web app and
82
+
retrieving some meaningful measurements.
78
83
79
84
This is generally done by other tools that retrieve the metrics.
80
85
One such tool is **_JMeter_**.
81
86
82
-
For a web application, details to measure include
87
+
For a web application, details to measure include
83
88
throughput, latency, data loss, individual component loading times, etc.
84
89
85
90
Note 1: All browsers have a performance tab in their
86
91
developers' tools section (accessible by pressing F12)
87
92
88
93
Note 2: is a subtype of **_non-functional testing_**
89
94
as this is generally measured per system and not per function/feature.
90
-
95
+
91
96
### Regression testing
92
-
This testing is generally done after a change, fix or feature addition.
93
97
94
-
To ensure that the change has not broken any of the existing
95
-
functionality, some already executed tests are executed again.
98
+
This testing is generally done after a change, fix or feature addition.
99
+
100
+
To ensure that the change has not broken any of the existing
101
+
functionality, some already executed tests are executed again.
96
102
97
103
>For example, **_Testing that your new search bar doesn't break the other buttons on the menu_**
98
-
104
+
99
105
The set of re-executed tests can be full or partial
100
106
and can include several different types, depending
101
107
on the application and development team.
102
-
108
+
103
109
### Test driven development (TDD)
110
+
104
111
Rather than a test type _per se_, TDD is an iterative
105
112
development methodology in which tests drive the design of a feature.
106
113
107
114
Each cycle starts by creating a set of unit tests that
108
115
the feature should eventually pass (they should fail their first time executed).
109
116
110
-
After this, development takes place to make the tests pass.
111
-
The tests are executed again, starting another cycle
117
+
After this, development takes place to make the tests pass.
118
+
The tests are executed again, starting another cycle
112
119
and this process continues until all tests are passing.
113
120
114
121
This aims to speed up the development of an application
115
122
based on the fact that defects are less costly the earlier they are found.
116
123
117
124
### Behavior-driven development (BDD)
118
-
BDD is also an iterative development methodology
119
-
based on the above TDD, in which the goal is to involve
120
-
all the parties in the development of an application.
121
-
122
-
Each cycle starts by creating some specifications
123
-
(which should fail). Then create the failing unit
124
-
tests (which should also fail) and then do the development.
125
-
126
-
This cycle is repeated until all types of tests are passing.
127
-
128
-
In order to do so, a specification language is
129
-
used. It should be understandable by all parties and
130
-
simple, standard and explicit.
131
-
Most tools use **_Gherkin_** as this language.
132
-
133
-
The goal is to be able to detect even more errors
134
-
than TDD, by targeting potential acceptance errors
135
-
too and make communication between parties smoother.
136
-
137
-
A set of tools are currently available
138
-
to write the specifications and match them with code functions,
139
-
such as **_Cucumber_** or **_SpecFlow._**
140
-
141
-
A set of tools are built on top of Selenium to make this process
142
-
even faster by directly transforming the BDD specifications into
143
-
executable code.
144
-
Some of these are **_JBehave, Capybara and Robot Framework_**.
145
-
125
+
126
+
Behavior-Driven Development (BDD) is an iterative methodology inspired by
127
+
TDD that focuses on defining system behavior through shared examples.
128
+
It emphasizes collaboration between business stakeholders, developers,
129
+
and testers to ensure a common understanding of requirements.
130
+
131
+
Development begins by defining specifications in a ubiquitous language,
132
+
commonly expressed using **_Gherkin_**. These specifications describe
133
+
expected behavior and serve as acceptance criteria.
134
+
Scenarios may initially fail when automated, guiding development until
135
+
the behavior is implemented.
136
+
137
+
BDD scenarios are supported by underlying code and tests, which may include:
138
+
unit, integration, or UI-level automation.
139
+
Tools such as Cucumber and SpecFlow enable mapping specifications
140
+
to executable code, often integrating with automation tools like Selenium.
141
+
142
+
The primary goal of BDD is to prevent misunderstandings and acceptance-level
143
+
defects by ensuring the right software is built from the start.
144
+
In common practice, Selenium is integrated with BDD frameworks
145
+
to automate browser-based behaviors described in BDD scenarios. In this setup:
146
+
147
+
BDD frameworks such as: **_Cucumber, JBehave, Capybara and Robot Framework_**
148
+
are responsible for parsing and managing specifications
149
+
**_Step definitions_** act as the bridge between human-readable scenarios
150
+
and executable code
151
+
152
+
Selenium as the automation engine to perform browser interactions
153
+
can be used in combination with the frameworks mentioned above as
154
+
an optional dependency that enables UI automation when browser-level validation is required.
0 commit comments