-
-
Save maltebucksch/d43ffc0af1170ef230b94c0bf0fe5630 to your computer and use it in GitHub Desktop.
| fun testTeamIsAwesome() { | |
| val quickBirdTeamMembers = fetchTeamMembers() | |
| val awesomeTeamMembers = quickBirdTeamMembers.filter { teamMember -> | |
| teamMember.isPassionate && | |
| teamMember.isFriendly && | |
| teamMember.isConstantlyImproving | |
| } | |
| assertEquals(quickBirdTeamMembers.size, awesomeTeamMembers.size) | |
| } |
Good thinking! 👍 I agree.
However, the point of the snippet was more to transfer our values in a fun way using code, not to be 100% technically bulletproof ;-) It's like saying "Why don't wizards in Harry Potter simply use (Muggle-)guns to fight each other?" - Yes, they could. But the movie loses its excitement then.
If you have a better example which transfers those values without being boring or complicated AND being technically bullet-proof: I am all ears --> send me the Gist 👍
Well, it sounds like it has to be matched between the number of QuickBird team members and number of QuickBird team members who is passionate, friendly, and constantly improving. If it does not match, then what will it happen? :) Is the contract member part of TeamMember? If contract member is passionate, friendly, and constantly improving, then add it to TeamMember and then it will pass the test.
Anyway, I am passionate, friendly, and constantly improving. I will send you email my resume. Check out my Github! :)
A unit test should test that fetchTeamMembers() function returns what suppose to need to return, not if the content itself is valid. If returned data content is not valid, either you have a bug on addTeamMember(member) function or you are accepting people on the team that not meet your requirements.
What about something like this?
This is a very important test I must say. I am enjoying the sense of humour in how your team organise, package and convey values. I have read the article about Gordon the smith, it is such captivating and all-encompassing of what a modern team should be.
About the team test, a good question is why add a team member that does not have all the three qualities - passionate, friendly and constantly improving? Given that we may not be able to tell immediately if someone possesses all these qualities, it suffices to say that there is a possibility for the test to fail. I would like to implement a notification pipeline to notify the team lead whenever the test fails as this is a critical situation. It should not fail for long, every fix has to be done within seconds to remedy the situation.
I understand it's just a fun form of your values representing but... an empty team will be still awesome. Am I wrong? 🙂
What about something like this?
Nice implementation of all of the surroundings! :-D makes sense from a coding point of view. But it seems a bit too complicated for conveying the message in a simple way inside the job posting. But I guess that wasn't your goal, so --> nice input 👍.
I would like to implement a notification pipeline to notify the team lead whenever the test fails as this is a critical situation. It should not fail for long, every fix has to be done within seconds to remedy the situation.
Makes sense! Might put too much pressure on the team because they have to be awesome every single minute. Everybody has a bad unproductive morning from time to time, and that's ok. So let's implement that pipeline but run it only once per week maybe? :)
I understand it's just a fun form of your values representing but... an empty team will be still awesome. Am I wrong? 🙂
Valid point. Leads to a philosophical discussion. Is a non-existent team awesome? 🤔 Hard to say. I'd also be inclined to think that a non-existent team doesn't add any value to the world, and is therefore not awesome. Might be a reason to adapt the test.
Hi! fetchTeamMembers() should be a suspend function, and you are not in a coroutine scope 🤔 . So I think that test will not work 🙂
On a second thought, I'm not so sure anymore if a unit test is the right choice here (and I guess that's why my intuition was pushing me towards implementing this as a function, not a test):
In my understanding, unit tests are for ensuring the correctness of our code (business logic), not for ensuring the correctness of our state (or data). Therefore, I think we should also not model team additions (which would be part of the normal program flow aka runtime) as unit tests, as appealing as it looks. 😉