I¡¯ve recently tried illustrating the Saff Squeeze in this GitHub repository:
I¡¯m not sure if I was doing a good job of executing the technique, let alone show-casing it. I¡¯d appreciate any comment you might have on it.?
Other than the original article rescued by the Wayback Machine and the I borrowed the production code to be squeezed from I wasn¡¯t able to find any more resources, either.?
¡ª
Daniel Ranner
|
You can reference Kent's original article via the wayback machine:
On Sat, Mar 26, 2022 at 12:32 AM Jacqueline Lee < jmasonlee@...> wrote: Hey J.B.?
Do you have this description of a Saff squeeze posted anywhere? I have a blog post that I'm writing that references a Saff squeeze, and I'd love to just link to a description rather than writing it up, but I can't find a good description elsewhere. Thanks!
On Fri, Mar 11, 2022 at 12:55 PM J. B. Rainsberger < me@...> wrote: One reasonable way to get from a few slow-running end-to-end tests to some strategic unit testing is to do the following whenever you encounter a bug:
[...]
Another suggestion: apply the Saff Squeeze. Think "debugging with automated tests".
Start with a failing test.
1. Inline the action of the test: that's the central function that you invoke to make the test _do_ something. 2. Make invisible things visible (private -> public in many languages). 3. Prune away dead code, such as the branches of an `if` statement that this test's input won't run. Maybe unroll a loop.
4. Add assertions to check intermediate results, especially the conditions of `if` statements or the stopping conditions of loops. Do this until you add an assertion that fails. 5. After you add a new failing assertion, delete the rest of the test; it won't execute, anyway.
Now you have a smaller test that fails for the same reason as the original test. Commit. Maybe now it's obvious what caused the defect. Yes? Fix it. No? Repeat the process.
This is one way to uncover smaller unit tests that would have helped you. Over time, you'll get to know which kinds of smaller unit tests you want to practise writing. -- J. B. (Joe) Rainsberger :: ?:: ::
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
|
Hey J.B.?
Do you have this description of a Saff squeeze posted anywhere? I have a blog post that I'm writing that references a Saff squeeze, and I'd love to just link to a description rather than writing it up, but I can't find a good description elsewhere. Thanks!
On Fri, Mar 11, 2022 at 12:55 PM J. B. Rainsberger < me@...> wrote: One reasonable way to get from a few slow-running end-to-end tests to some strategic unit testing is to do the following whenever you encounter a bug:
[...]
Another suggestion: apply the Saff Squeeze. Think "debugging with automated tests".
Start with a failing test.
1. Inline the action of the test: that's the central function that you invoke to make the test _do_ something. 2. Make invisible things visible (private -> public in many languages). 3. Prune away dead code, such as the branches of an `if` statement that this test's input won't run. Maybe unroll a loop.
4. Add assertions to check intermediate results, especially the conditions of `if` statements or the stopping conditions of loops. Do this until you add an assertion that fails. 5. After you add a new failing assertion, delete the rest of the test; it won't execute, anyway.
Now you have a smaller test that fails for the same reason as the original test. Commit. Maybe now it's obvious what caused the defect. Yes? Fix it. No? Repeat the process.
This is one way to uncover smaller unit tests that would have helped you. Over time, you'll get to know which kinds of smaller unit tests you want to practise writing. -- J. B. (Joe) Rainsberger :: ?:: ::
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
|
One reasonable way to get from a few slow-running end-to-end tests to some strategic unit testing is to do the following whenever you encounter a bug:
[...]
Another suggestion: apply the Saff Squeeze. Think "debugging with automated tests".
Start with a failing test.
1. Inline the action of the test: that's the central function that you invoke to make the test _do_ something. 2. Make invisible things visible (private -> public in many languages). 3. Prune away dead code, such as the branches of an `if` statement that this test's input won't run. Maybe unroll a loop.
4. Add assertions to check intermediate results, especially the conditions of `if` statements or the stopping conditions of loops. Do this until you add an assertion that fails. 5. After you add a new failing assertion, delete the rest of the test; it won't execute, anyway.
Now you have a smaller test that fails for the same reason as the original test. Commit. Maybe now it's obvious what caused the defect. Yes? Fix it. No? Repeat the process.
This is one way to uncover smaller unit tests that would have helped you. Over time, you'll get to know which kinds of smaller unit tests you want to practise writing. -- J. B. (Joe) Rainsberger :: ?:: ::
-- J. B. (Joe) Rainsberger :: :: :: Teaching evolutionary design and TDD since 2002
|
One reasonable way to get from a few slow-running end-to-end tests to some strategic unit testing is to do the following whenever you encounter a bug:
1. Once you have diagnosed the bug, verify your diagnosis with at least one unit test on the function/object/component that you believe is at fault.? If your diagnosis is good, then that test should fail before you fix the bug and pass after you fix the bug.? If it turns out that the fix is insufficient to fix the bug, figure out what else is wrong and write one or more tests for that failure.
This way, you avoid the compulsion/burden to cover the entire system with unit tests, instead just putting them where failures have been found (which makes those places more likely to have future failures than other random functions/objects/components of the system).? Accumulate these unit tests and run them frequently, since they are fast.
On Thu, Mar 10, 2022 at 10:26 AM Tim Ottinger < tottinge@...> wrote: JB's done a great job here.
Selenium has its place, of course, but my usual heartburn is that you have to have a full system (even if some are mocks) stood up and then you have to do a lot of waiting for the next dialog/action/reaction to occur. That usually means that 1 selenium test takes longer to run than hundreds of what we might call "unit tests" or "microtests". If you're going from no tests to 'stand it up and test something' then that's not the most important consideration.
You could, of course, have a selenium?'setup' test (background, whatever you want to call it) that logs in once and you use the login for all your other selenium tests, but this is slow and tends to be more fragile and unfun than unit tests.
Following Joe's suggestions is a better path in general, I'd say.
In one recent app, we extracted a function for 'checkAuthn' so that we could override it with mocks. Then, rather than deal with tokens and the like, we tell that function to report the current user is (guest|author|admin|etc) and bypass the whole authentication/authorization thing. You might also make an overrideable?function for "is current user allowed to do this action": a mock returns 'yes' or 'no' depending on the need of your test.
You can get a lot of mileage out of "extract function so you can mock it" in proper micro/unit tests.
On Thu, Mar 10, 2022 at 6:20 AM J. B. Rainsberger < me@...> wrote: I'm a desktop software developer getting into web development, using C# at present.? Also aiming to do Angular.? I'm fishing for strategies, techniques, tools I should be using to test stuff.? My current scenario is my application starts in a web browser, connects to my web server, requires the user to login (OAuth2) to a 3rd party service.? After login, the main path is for the browser to pose queries to my server, which it fulfills by using this 3rd party.
I can do all these things.? My confusion comes trying to write unit tests, integration tests, etc.? There is no user to login, so how does one get started?? Beyond that, I'm not greatly familiar with web stack software and so the fashion of doing TDD is also unfamiliar to me.? Can you guide me?? Can you point me to a guide?? Beyond NUnit, what do you recommend for testing my server?
First things first: if you can imagine an action and an expected result, then you have enough information to write a test. Start there. You will probably find that you write mostly end-to-end tests. This makes many programmers nervous because they read articles telling them not to do this. I advise you to ignore those articles for now, even though I've written some of them.
Instead, write any test that you know how to write. It will feel slow; let it feel slow.
Eventually you'll notice _specific aspects_ of your tests that you don't like. These will be the repeated annoyances that actually bother you right now. When you find those, ask us again for how to overcome them.
I can anticipate one such annoyance: login. When we add authentication, we have to change every end-to-end test to start with "user logs in", even when 90% of our tests don't actually care about a user logging in. Let me be clear: these are not tests that assume that we have an authenticated user; they are tests that prefer to ignore authentication entirely. The difference is largely theoretical, but it matters to me. I want to move such tests "under the skin", below the part of the system that wants to protect web pages from unauthorized access. These are no longer web site tests; they are some other kind of test. Accordingly, I want to write narrower/smaller tests (ones that run a smaller part of the system).
We call those "unit tests", because they treat a smaller part of the system as a self-contained unit. Other people have strange definitions of "unit test". You'll get used to it. :P
For now, it's enough to treat "unit tests" as "tests that talk _below_ the HTTP layer". They check the logic of the code without worrying about how we expose that logic over HTTP. Try to write such a test. How difficult is it to try a convincing test that doesn't even know that HTTP exists somewhere above it? That difficulty points to unhealthy dependencies in your design: code that doesn't need to know that it's running over HTTP, but that can't run without HTTP.
I want less of that code, for a variety of reasons. The most immediate reason for you is that it's easier to test code that doesn't even know that HTTP exists.
You can now also start from the inside out: find the parts of your code that already run entirely in memory (no HTTP, no files, nothing outside) and try to write tests for that code. Those tests might seem naive and useless, but you're practising writing tests (at all), so that's OK. Gradually you'll realize "this code would be easier to test if it ran entirely in memory... and I think I can make it do that". Make it do that.
I think this gives you a place to continue. What follow-up questions does it raise for you? Which questions does it settle for you? -- J. B. (Joe) Rainsberger :: ?:: ::
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
--
Peace, Tim
-------------------------------------
|
JB's done a great job here.
Selenium has its place, of course, but my usual heartburn is that you have to have a full system (even if some are mocks) stood up and then you have to do a lot of waiting for the next dialog/action/reaction to occur. That usually means that 1 selenium test takes longer to run than hundreds of what we might call "unit tests" or "microtests". If you're going from no tests to 'stand it up and test something' then that's not the most important consideration.
You could, of course, have a selenium?'setup' test (background, whatever you want to call it) that logs in once and you use the login for all your other selenium tests, but this is slow and tends to be more fragile and unfun than unit tests.
Following Joe's suggestions is a better path in general, I'd say.
In one recent app, we extracted a function for 'checkAuthn' so that we could override it with mocks. Then, rather than deal with tokens and the like, we tell that function to report the current user is (guest|author|admin|etc) and bypass the whole authentication/authorization thing. You might also make an overrideable?function for "is current user allowed to do this action": a mock returns 'yes' or 'no' depending on the need of your test.
You can get a lot of mileage out of "extract function so you can mock it" in proper micro/unit tests.
On Thu, Mar 10, 2022 at 6:20 AM J. B. Rainsberger < me@...> wrote: I'm a desktop software developer getting into web development, using C# at present.? Also aiming to do Angular.? I'm fishing for strategies, techniques, tools I should be using to test stuff.? My current scenario is my application starts in a web browser, connects to my web server, requires the user to login (OAuth2) to a 3rd party service.? After login, the main path is for the browser to pose queries to my server, which it fulfills by using this 3rd party.
I can do all these things.? My confusion comes trying to write unit tests, integration tests, etc.? There is no user to login, so how does one get started?? Beyond that, I'm not greatly familiar with web stack software and so the fashion of doing TDD is also unfamiliar to me.? Can you guide me?? Can you point me to a guide?? Beyond NUnit, what do you recommend for testing my server?
First things first: if you can imagine an action and an expected result, then you have enough information to write a test. Start there. You will probably find that you write mostly end-to-end tests. This makes many programmers nervous because they read articles telling them not to do this. I advise you to ignore those articles for now, even though I've written some of them.
Instead, write any test that you know how to write. It will feel slow; let it feel slow.
Eventually you'll notice _specific aspects_ of your tests that you don't like. These will be the repeated annoyances that actually bother you right now. When you find those, ask us again for how to overcome them.
I can anticipate one such annoyance: login. When we add authentication, we have to change every end-to-end test to start with "user logs in", even when 90% of our tests don't actually care about a user logging in. Let me be clear: these are not tests that assume that we have an authenticated user; they are tests that prefer to ignore authentication entirely. The difference is largely theoretical, but it matters to me. I want to move such tests "under the skin", below the part of the system that wants to protect web pages from unauthorized access. These are no longer web site tests; they are some other kind of test. Accordingly, I want to write narrower/smaller tests (ones that run a smaller part of the system).
We call those "unit tests", because they treat a smaller part of the system as a self-contained unit. Other people have strange definitions of "unit test". You'll get used to it. :P
For now, it's enough to treat "unit tests" as "tests that talk _below_ the HTTP layer". They check the logic of the code without worrying about how we expose that logic over HTTP. Try to write such a test. How difficult is it to try a convincing test that doesn't even know that HTTP exists somewhere above it? That difficulty points to unhealthy dependencies in your design: code that doesn't need to know that it's running over HTTP, but that can't run without HTTP.
I want less of that code, for a variety of reasons. The most immediate reason for you is that it's easier to test code that doesn't even know that HTTP exists.
You can now also start from the inside out: find the parts of your code that already run entirely in memory (no HTTP, no files, nothing outside) and try to write tests for that code. Those tests might seem naive and useless, but you're practising writing tests (at all), so that's OK. Gradually you'll realize "this code would be easier to test if it ran entirely in memory... and I think I can make it do that". Make it do that.
I think this gives you a place to continue. What follow-up questions does it raise for you? Which questions does it settle for you? -- J. B. (Joe) Rainsberger :: ?:: ::
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
-- Peace, Tim
-------------------------------------
|
toggle quoted message
Show quoted text
On Thu, Mar 10, 2022 at 6:20 AM J. B. Rainsberger < me@...> wrote: I'm a desktop software developer getting into web development, using C# at present.? Also aiming to do Angular.? I'm fishing for strategies, techniques, tools I should be using to test stuff.? My current scenario is my application starts in a web browser, connects to my web server, requires the user to login (OAuth2) to a 3rd party service.? After login, the main path is for the browser to pose queries to my server, which it fulfills by using this 3rd party.
I can do all these things.? My confusion comes trying to write unit tests, integration tests, etc.? There is no user to login, so how does one get started?? Beyond that, I'm not greatly familiar with web stack software and so the fashion of doing TDD is also unfamiliar to me.? Can you guide me?? Can you point me to a guide?? Beyond NUnit, what do you recommend for testing my server?
First things first: if you can imagine an action and an expected result, then you have enough information to write a test. Start there. You will probably find that you write mostly end-to-end tests. This makes many programmers nervous because they read articles telling them not to do this. I advise you to ignore those articles for now, even though I've written some of them.
Instead, write any test that you know how to write. It will feel slow; let it feel slow.
Eventually you'll notice _specific aspects_ of your tests that you don't like. These will be the repeated annoyances that actually bother you right now. When you find those, ask us again for how to overcome them.
I can anticipate one such annoyance: login. When we add authentication, we have to change every end-to-end test to start with "user logs in", even when 90% of our tests don't actually care about a user logging in. Let me be clear: these are not tests that assume that we have an authenticated user; they are tests that prefer to ignore authentication entirely. The difference is largely theoretical, but it matters to me. I want to move such tests "under the skin", below the part of the system that wants to protect web pages from unauthorized access. These are no longer web site tests; they are some other kind of test. Accordingly, I want to write narrower/smaller tests (ones that run a smaller part of the system).
We call those "unit tests", because they treat a smaller part of the system as a self-contained unit. Other people have strange definitions of "unit test". You'll get used to it. :P
For now, it's enough to treat "unit tests" as "tests that talk _below_ the HTTP layer". They check the logic of the code without worrying about how we expose that logic over HTTP. Try to write such a test. How difficult is it to try a convincing test that doesn't even know that HTTP exists somewhere above it? That difficulty points to unhealthy dependencies in your design: code that doesn't need to know that it's running over HTTP, but that can't run without HTTP.
I want less of that code, for a variety of reasons. The most immediate reason for you is that it's easier to test code that doesn't even know that HTTP exists.
You can now also start from the inside out: find the parts of your code that already run entirely in memory (no HTTP, no files, nothing outside) and try to write tests for that code. Those tests might seem naive and useless, but you're practising writing tests (at all), so that's OK. Gradually you'll realize "this code would be easier to test if it ran entirely in memory... and I think I can make it do that". Make it do that.
I think this gives you a place to continue. What follow-up questions does it raise for you? Which questions does it settle for you? -- J. B. (Joe) Rainsberger :: ?:: ::
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
|
I'm a desktop software developer getting into web development, using C# at present.? Also aiming to do Angular.? I'm fishing for strategies, techniques, tools I should be using to test stuff.? My current scenario is my application starts in a web browser, connects to my web server, requires the user to login (OAuth2) to a 3rd party service.? After login, the main path is for the browser to pose queries to my server, which it fulfills by using this 3rd party.
I can do all these things.? My confusion comes trying to write unit tests, integration tests, etc.? There is no user to login, so how does one get started?? Beyond that, I'm not greatly familiar with web stack software and so the fashion of doing TDD is also unfamiliar to me.? Can you guide me?? Can you point me to a guide?? Beyond NUnit, what do you recommend for testing my server?
First things first: if you can imagine an action and an expected result, then you have enough information to write a test. Start there. You will probably find that you write mostly end-to-end tests. This makes many programmers nervous because they read articles telling them not to do this. I advise you to ignore those articles for now, even though I've written some of them.
Instead, write any test that you know how to write. It will feel slow; let it feel slow.
Eventually you'll notice _specific aspects_ of your tests that you don't like. These will be the repeated annoyances that actually bother you right now. When you find those, ask us again for how to overcome them.
I can anticipate one such annoyance: login. When we add authentication, we have to change every end-to-end test to start with "user logs in", even when 90% of our tests don't actually care about a user logging in. Let me be clear: these are not tests that assume that we have an authenticated user; they are tests that prefer to ignore authentication entirely. The difference is largely theoretical, but it matters to me. I want to move such tests "under the skin", below the part of the system that wants to protect web pages from unauthorized access. These are no longer web site tests; they are some other kind of test. Accordingly, I want to write narrower/smaller tests (ones that run a smaller part of the system).
We call those "unit tests", because they treat a smaller part of the system as a self-contained unit. Other people have strange definitions of "unit test". You'll get used to it. :P
For now, it's enough to treat "unit tests" as "tests that talk _below_ the HTTP layer". They check the logic of the code without worrying about how we expose that logic over HTTP. Try to write such a test. How difficult is it to try a convincing test that doesn't even know that HTTP exists somewhere above it? That difficulty points to unhealthy dependencies in your design: code that doesn't need to know that it's running over HTTP, but that can't run without HTTP.
I want less of that code, for a variety of reasons. The most immediate reason for you is that it's easier to test code that doesn't even know that HTTP exists.
You can now also start from the inside out: find the parts of your code that already run entirely in memory (no HTTP, no files, nothing outside) and try to write tests for that code. Those tests might seem naive and useless, but you're practising writing tests (at all), so that's OK. Gradually you'll realize "this code would be easier to test if it ran entirely in memory... and I think I can make it do that". Make it do that.
I think this gives you a place to continue. What follow-up questions does it raise for you? Which questions does it settle for you? -- J. B. (Joe) Rainsberger :: ?:: ::
-- J. B. (Joe) Rainsberger :: :: :: Teaching evolutionary design and TDD since 2002
|
I¡¯m not familiar with JWT. A search says ¡°json web tokens¡±, and I suppose maybe this is a widelly used system of token definition? Re automate a post, I¡¯m not sure what that post is, but maybe I can inspect the javascript of the login page and replicate what it does in my own code to figure out what to post.
Or as somebody said Selenium, maybe I can learn that tool and use it to do some webpage clicking for me?
toggle quoted message
Show quoted text
On Mar 9, 2022, at 15:50, Tim Ottinger <tottinge@...> wrote:
?
I¡¯ve done this in some apps, creating a JWT that satisfies the app¡¯s needs.
I¡¯m interested if the service can¡¯t be bypassed as George says or at least you could automate a post, extract the token, and use it for all the rest of the tests.
Whether you write your own post (not as bad) or go through the login screens (ugh) logging in is extra work.
Tim
--
|
I am testing a combo of the service API¡¯s and the test data I put into the service manually. The service itself is reliable and doesn¡¯t change much, but as I develop the test data, that¡¯s a likely spot for things to break. Automated tests that I can just run ¡°is everything good¡± is a huge remedy for this.
toggle quoted message
Show quoted text
On Mar 9, 2022, at 14:35, George Dinwiddie <lists@...> wrote:
?Alan, well, maybe not. Are you testing the functionality of that service, or functionality that you are creating?
- George
On 3/9/22 8:35 AM, Alan Baljeu via groups.io wrote:
Is that possible? I don¡¯t create auth tokens, but the service I consume does this.
On Mar 8, 2022, at 20:00, George Dinwiddie <lists@...> wrote: ?Alan,
Create an auth token in a setup method and use that. I would do so by calling the needed code directly rather than navigating to /login. You don't need an extra dependency on the URL structure.
- George
On 3/8/22 7:15 PM, Alan Baljeu via groups.io wrote:
I will keep Selenium in mind for future when I¡¯m doing UI work.
Maybe I can get more specific with my present concern.
I create an API service /xyz. That works by calling a 3rd party service but only works if I have an auth token. Otherwise it returns http redirect to the login page. Or maybe it should return ¡°Unauthorized¡± and my Javascript should react to this by navigating to /login.
In either case, now I want to write a test for /xyz. But this test cannot pass unless I have a token, that is only obtained by following the login process. So how can I write a test of /xyz? Maybe in the short term I just manually login for the server and then run all the tests, but longterm I want to avoid this. I must be missing some secret of how these things are done.
On Mar 8, 2022, at 13:28, Vijay via groups.io <vijay_nathani@...> wrote: ?NUnit is Ok for Unit Testing C# code.
For the Integration tests, you can use NUnit. Just ensure that these tests can be run seprately.
For UI testing, you will can add selenium to NUnit.
_._,_._,_ --
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
|
I¡¯ve done this in some apps, creating a JWT that satisfies the app¡¯s needs. I¡¯m interested if the service can¡¯t be bypassed as George says or at least you could automate a post, extract the token, and use it for all the rest of the tests.
Whether you write your own post (not as bad) or go through the login screens (ugh) logging in is extra work.?
Tim -- Peace, Tim
-------------------------------------
|
Alan, well, maybe not. Are you testing the functionality of that service, or functionality that you are creating?
- George
toggle quoted message
Show quoted text
On 3/9/22 8:35 AM, Alan Baljeu via groups.io wrote: Is that possible? I don¡¯t create auth tokens, but the service I consume does this.
On Mar 8, 2022, at 20:00, George Dinwiddie <lists@...> wrote:
?Alan,
Create an auth token in a setup method and use that. I would do so by calling the needed code directly rather than navigating to /login. You don't need an extra dependency on the URL structure.
- George
On 3/8/22 7:15 PM, Alan Baljeu via groups.io wrote:
I will keep Selenium in mind for future when I¡¯m doing UI work.
Maybe I can get more specific with my present concern.
I create an API service /xyz. That works by calling a 3rd party service but only works if I have an auth token. Otherwise it returns http redirect to the login page. Or maybe it should return ¡°Unauthorized¡± and my Javascript should react to this by navigating to /login.
In either case, now I want to write a test for /xyz. But this test cannot pass unless I have a token, that is only obtained by following the login process. So how can I write a test of /xyz? Maybe in the short term I just manually login for the server and then run all the tests, but longterm I want to avoid this. I must be missing some secret of how these things are done.
On Mar 8, 2022, at 13:28, Vijay via groups.io <vijay_nathani@...> wrote: ?NUnit is Ok for Unit Testing C# code.
For the Integration tests, you can use NUnit. Just ensure that these tests can be run seprately.
For UI testing, you will can add selenium to NUnit.
_._,_._,_ --
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
|
Is that possible? I don¡¯t create auth tokens, but the service I consume does this.
toggle quoted message
Show quoted text
On Mar 8, 2022, at 20:00, George Dinwiddie <lists@...> wrote:
?Alan,
Create an auth token in a setup method and use that. I would do so by calling the needed code directly rather than navigating to /login. You don't need an extra dependency on the URL structure.
- George
On 3/8/22 7:15 PM, Alan Baljeu via groups.io wrote:
I will keep Selenium in mind for future when I¡¯m doing UI work.
Maybe I can get more specific with my present concern.
I create an API service /xyz. That works by calling a 3rd party service but only works if I have an auth token. Otherwise it returns http redirect to the login page. Or maybe it should return ¡°Unauthorized¡± and my Javascript should react to this by navigating to /login.
In either case, now I want to write a test for /xyz. But this test cannot pass unless I have a token, that is only obtained by following the login process. So how can I write a test of /xyz? Maybe in the short term I just manually login for the server and then run all the tests, but longterm I want to avoid this. I must be missing some secret of how these things are done.
On Mar 8, 2022, at 13:28, Vijay via groups.io <vijay_nathani@...> wrote: ?NUnit is Ok for Unit Testing C# code.
For the Integration tests, you can use NUnit. Just ensure that these tests can be run seprately.
For UI testing, you will can add selenium to NUnit.
_._,_._,_ --
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
|
Alan,
Create an auth token in a setup method and use that. I would do so by calling the needed code directly rather than navigating to /login. You don't need an extra dependency on the URL structure.
- George
toggle quoted message
Show quoted text
On 3/8/22 7:15 PM, Alan Baljeu via groups.io wrote: I will keep Selenium in mind for future when I¡¯m doing UI work.
Maybe I can get more specific with my present concern.
I create an API service /xyz. ?That works by calling a 3rd party service but only works if I have an auth token. ?Otherwise it returns http redirect to the login page. ?Or maybe it should return ¡°Unauthorized¡± and my Javascript should react to this by navigating to /login.
In either case, now I want to write a test for /xyz. ?But this test cannot pass unless I have a token, that is only obtained by following the login process. ?So how can I write a test of /xyz? ?Maybe in the short term I just manually login for the server and then run all the tests, but longterm I want to avoid this. ?I must be missing some secret of how these things are done.
On Mar 8, 2022, at 13:28, Vijay via groups.io <vijay_nathani@...> wrote:
?NUnit is Ok for Unit Testing C# code.
For the Integration tests, you can use NUnit. Just ensure that these tests can be run seprately.
For UI testing, you will can add selenium to NUnit. _._,_._,_
--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
|
I will keep Selenium in mind for future when I¡¯m doing UI work. Maybe I can get more specific with my present concern.
I create an API service /xyz. ?That works by calling a 3rd party service but only works if I have an auth token. ?Otherwise it returns http redirect to the login page. ?Or maybe it should return ¡°Unauthorized¡± and my Javascript should react to this by navigating to /login.
In either case, now I want to write a test for /xyz. ?But this test cannot pass unless I have a token, that is only obtained by following the login process. ?So how can I write a test of /xyz? ?Maybe in the short term I just manually login for the server and then run all the tests, but longterm I want to avoid this. ?I must be missing some secret of how these things are done.
toggle quoted message
Show quoted text
On Mar 8, 2022, at 13:28, Vijay via groups.io <vijay_nathani@...> wrote:
?NUnit is Ok for Unit Testing C# code.
For the Integration tests, you can use NUnit. Just ensure that these tests can be run seprately.
For UI testing, you will can add selenium to NUnit.
|
NUnit is Ok for Unit Testing C# code.
For the Integration tests, you can use NUnit. Just ensure that these tests can be run seprately.
For UI testing, you will can add selenium to NUnit.
|
My prime concern now is to test the backend which is C#, and through the third party webservice.
On Tuesday, March 8, 2022, 10:36:22 a.m. EST, Mark Levison <mark@...> wrote:
Alan - I went full bore about a year ago into learning JavaScript for the purposes of creating this game:?
I hired someone to help me write the scaffolding and the UI basics. I coded the rule sets.?
This book was very helpful in seeing how to write JavaScript:?
?The book is interesting to you as it is full of tests that help you explore JS.
From what I noticed working with my developer React is very testable if you don't mind stuff running through the browser. As to testing without a logged in user, some form of fake has often helped me in the past.
Cheers
Mark
|
Alan - I went full bore about a year ago into learning JavaScript for the purposes of creating this game:?
I hired someone to help me write the scaffolding and the UI basics. I coded the rule sets.?
This book was very helpful in seeing how to write JavaScript:?
?The book is interesting to you as it is full of tests that help you explore JS.
From what I noticed working with my developer React is very testable if you don't mind stuff running through the browser. As to testing without a logged in user, some form of fake has often helped me in the past.
Cheers
Mark
|
Alan On 3/8/22 8:33 AM, Alan Baljeu via groups.io wrote: I'm a desktop software developer getting into web development, using C# at present.? Also aiming to do Angular.? I'm fishing for strategies, techniques, tools I should be using to test stuff.? My current scenario is my application starts in a web browser, connects to my web server, requires the user to login (OAuth2) to a 3rd party service.? After login, the main path is for the browser to pose queries to my server, which it fulfills by using this 3rd party.
I can do all these things.? My confusion comes trying to write unit tests, integration tests, etc.? There is no user to login, so how does one get started? Let go of the "nuts and bolts" view for a moment and think about what you're trying to accomplish. The login is just an implementation detail. (I talked about this in and ) For tests that depend on being logged in, but aren't about logging in, you can login a test-user during test setup. Beyond that, I'm not greatly familiar with web stack software and so the fashion of doing TDD is also unfamiliar to me.? Can you guide me?? Can you point me to a guide?? Beyond NUnit, what do you recommend for testing my server? My experience with Angular (several years old now) was that it makes it difficult to do things I expect to be simple, such as inject a test-double service on the fly in a test setup. - George -- ---------------------------------------------------------------------- * George Dinwiddie * Software Development Consultant and Coach ----------------------------------------------------------------------
|
I'm a desktop software developer getting into web development, using C# at present.? Also aiming to do Angular.? I'm fishing for strategies, techniques, tools I should be using to test stuff.? My current scenario is my application starts in a web browser, connects to my web server, requires the user to login (OAuth2) to a 3rd party service.? After login, the main path is for the browser to pose queries to my server, which it fulfills by using this 3rd party.
I can do all these things.? My confusion comes trying to write unit tests, integration tests, etc.? There is no user to login, so how does one get started?? Beyond that, I'm not greatly familiar with web stack software and so the fashion of doing TDD is also unfamiliar to me.? Can you guide me?? Can you point me to a guide?? Beyond NUnit, what do you recommend for testing my server?
|
Daniel Ranner
J. B. Rainsberger
Mark Levison