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
This issue collects the feedback and notes we got from giving the course yesterday.
Unclear level definitions
We talk about tests as Level 0-3 all the time, but the participants forget what each level represents, which makes the cognitive load unnecessarily high. One approach that we discussed is that we should have a large poster that explains the levels, or write them on a whiteboard, or similar.
Also, for the purposes of the lab excersices, we where not perfectly clear about the definitions of each level. The slide that we show talks defines each level in terms of examples, and suggestions; we need clear definitions for the source code examples and labs to work.
So for the purposes of the lab excerices, we should clearly define the levels accordingly:
L0 - Classic unit test with mocked dependencies
L1 - Test that verifies database round-trips (non-hosted service)
L2 - HTTP calls against the hosted service, mocked external dependencies
L3 - HTTP calls against the hosted service, including external dependencies
L1 tests against service or repository class?
A question that came up was that we target the service class BasketService in the L1 tests. Why not target the repository instead? There are pros and cons to both approaches, and resulted in an interresting discussion. Maybe we can add some notes to the presentation, or in README.md or TEACHER.md about this?
Hosted product service contains duplicate ids
The hosted product service returns a set of products that all have the same id, which raised questions. The current implementation is done using Azure Functions for simplicity and cost effectiveness, but it limits what we can do. Maybe we should setup a real REST service so that we can return a much larger, correct set of products that also changes for every request?
Hosted MongoDB or local installation?
Emailing the credentials for the hosted MongoDB had all the problems that we anticipated. Should we instead point people to using a MongoDB docker image? Try it out and see that that means.
The time for Lab/2
We used 40 minutes for lab/2, and it seemed like this was about right. We should update the slide notes and the TEACHER.md files about this. This was a group of strong developers, we can expect other groups to perhaps needing even more time.
We did not do Lab/3
The purpose of lab/3 is to run the same tests against a hosted service that is configured for the external product service. We never did this, but instead just talked about it. It felt like it was better to keep the momentum of the presentation and talk about running against a production environment instead.
Maybe we can demo lab/3 instead? We would then just checkout the master branch, run the L2 tests and watch them pass, configure the service to use the production product service URL and run the tests again. Update the slides if we do.
Use two computers
We switch back and forth between showing source code and the PowerPoint presentation a lot. Using two dedicated computers for each purpose would result in a much smoother, and professional presentation. Get a KVM switch, it will probably make a big difference.
Better invitation email
The students could have come much better prepared if the invitation had contained better instructions:
At least build the master branch at home (pull all dependencies)
Run all the tests and see that L0 pass and L1-3 does not
Follow the instructions and connect to a MongoDB, and run L1-3
The text was updated successfully, but these errors were encountered:
This issue collects the feedback and notes we got from giving the course yesterday.
Unclear level definitions
We talk about tests as Level 0-3 all the time, but the participants forget what each level represents, which makes the cognitive load unnecessarily high. One approach that we discussed is that we should have a large poster that explains the levels, or write them on a whiteboard, or similar.
Also, for the purposes of the lab excersices, we where not perfectly clear about the definitions of each level. The slide that we show talks defines each level in terms of examples, and suggestions; we need clear definitions for the source code examples and labs to work.
So for the purposes of the lab excerices, we should clearly define the levels accordingly:
L0 - Classic unit test with mocked dependencies
L1 - Test that verifies database round-trips (non-hosted service)
L2 - HTTP calls against the hosted service, mocked external dependencies
L3 - HTTP calls against the hosted service, including external dependencies
L1 tests against service or repository class?
A question that came up was that we target the service class
BasketService
in the L1 tests. Why not target the repository instead? There are pros and cons to both approaches, and resulted in an interresting discussion. Maybe we can add some notes to the presentation, or in README.md or TEACHER.md about this?Hosted product service contains duplicate ids
The hosted product service returns a set of products that all have the same id, which raised questions. The current implementation is done using Azure Functions for simplicity and cost effectiveness, but it limits what we can do. Maybe we should setup a real REST service so that we can return a much larger, correct set of products that also changes for every request?
Hosted MongoDB or local installation?
Emailing the credentials for the hosted MongoDB had all the problems that we anticipated. Should we instead point people to using a MongoDB docker image? Try it out and see that that means.
The time for Lab/2
We used 40 minutes for lab/2, and it seemed like this was about right. We should update the slide notes and the TEACHER.md files about this. This was a group of strong developers, we can expect other groups to perhaps needing even more time.
We did not do Lab/3
The purpose of lab/3 is to run the same tests against a hosted service that is configured for the external product service. We never did this, but instead just talked about it. It felt like it was better to keep the momentum of the presentation and talk about running against a production environment instead.
Maybe we can demo lab/3 instead? We would then just checkout the master branch, run the L2 tests and watch them pass, configure the service to use the production product service URL and run the tests again. Update the slides if we do.
Use two computers
We switch back and forth between showing source code and the PowerPoint presentation a lot. Using two dedicated computers for each purpose would result in a much smoother, and professional presentation. Get a KVM switch, it will probably make a big difference.
Better invitation email
The students could have come much better prepared if the invitation had contained better instructions:
The text was updated successfully, but these errors were encountered: